Re: Promise TX4200 support?

[Martin Povolný]

Daniel Drake wrote:
> Hi Martin,
> 
> Martin Povolný wrote:
> 
>> We are succesfully running patched sata_promise with 3 disks in a
>> raid5/raid1 setup. (Patched against ubuntu linux-image 2.6.11-1-686
>> package.)
> 
> 
> Could you please either send in your patch, or tell me which board_
> setting (2037x/20319/20619) the device ID table should include so I can
> write submit one myself.
> 

For me it works with 20319, but I don't understand the difference
between different settings.

*** sata_promise.c  2005-05-11 21:22:20.0 +0200
--- sata_promise_new.c  2005-05-11 21:22:02.0 +0200
***
*** 164,171 
--- 164,173 
{ PCI_VENDOR_ID_PROMISE, 0x3318, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
  board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
  board_20319 },
+   { PCI_VENDOR_ID_PROMISE, 0x3519, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
  board_20319 },

{ } /* terminate list */

Regards,

-- 
Mgr. Martin Povolný, soLNet, s.r.o.,
+42014458, [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] pci_find_device --> pci_get_device

[Rogier Wolff]

On Tue, Jul 19, 2005 at 02:25:23AM +0200, Jiri Slaby wrote:
> The patch is for mixed files from all over the tree.
> 
> Kernel version: 2.6.13-rc3-git4
> 
> * This patch removes from kernel tree pci_find_device and changes
> it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
> count of the variable.
> * Next, there are some (about 10 or so) gcc warning problems (i. e.
> variable may be unitialized) solutions, which were around code with old
> pci_find_device.
> * Some code was unpretty, or ugly, so the patch provides more readable
> code, in some cases.
> * Marks the function as deprecated in pci.h

Hi Jiri, 

The patch grabs reference counts to pdev structures, but almost never
decreases the reference counts. 

If you are working in a team, and want others to be able to continue
where you left off, you should add a comment, even if it is repetitive
to state what needs to be done. 

As far as I can see, you grab a reference to the "pdev" on 
initialization, and never release it. Or you only release it in 
certain error conditions. Would this make the driver unable to 
be unloaded and reloaded? That would not be good. 

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
-
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] compat: be more consistent about [ug]id_t

[Stephen Rothwell]

Hi all,

When I first wrote the compat layer patches, I was somewhat cavalier about the
definition of compat_uid_t and compat_gid_t (or maybe I just misunderstood :-)).
This patch makes the compat types much more consistent with the types we are 
being
compatible with and hopefully will fix a few bugs along the way.

compat type type in compat arch
__compat_[ug]id_t   __kernel_[ug]id_t
__compat_[ug]id32_t __kernel_[ug]id32_t
compat_[ug]id_t [ug]id_t

The difference is that compat_uid_t is always 32 bits (for the archs we care 
about) but
__compat_uid_t may be 16 bits on some.

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 arch/mips/kernel/linux32.c   |   16 
 fs/compat.c  |   16 
 include/asm-ia64/compat.h|   20 ++--
 include/asm-mips/compat.h|   10 ++
 include/asm-parisc/compat.h  |   10 ++
 include/asm-ppc64/compat.h   |   18 ++
 include/asm-s390/compat.h|   20 ++--
 include/asm-sparc64/compat.h |   18 ++
 include/asm-x86_64/compat.h  |   20 ++--
 include/linux/compat.h   |3 +++
 ipc/compat.c |   12 ++--
 11 files changed, 87 insertions(+), 76 deletions(-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/

diff -ruNp linus/arch/mips/kernel/linux32.c 
linus-compat_uid_t/arch/mips/kernel/linux32.c
--- linus/arch/mips/kernel/linux32.c2005-06-27 16:08:00.0 +1000
+++ linus-compat_uid_t/arch/mips/kernel/linux32.c   2005-06-27 
17:40:08.0 +1000
@@ -546,20 +546,20 @@ struct msgbuf32 { s32 mtype; char mtext[
 struct ipc_perm32
 {
key_t key;
-compat_uid_t  uid;
-compat_gid_t  gid;
-compat_uid_t  cuid;
-compat_gid_t  cgid;
+__compat_uid_t  uid;
+__compat_gid_t  gid;
+__compat_uid_t  cuid;
+__compat_gid_t  cgid;
 compat_mode_t  mode;
 unsigned short  seq;
 };
 
 struct ipc64_perm32 {
key_t key;
-   compat_uid_t uid;
-   compat_gid_t gid;
-   compat_uid_t cuid;
-   compat_gid_t cgid;
+   __compat_uid_t uid;
+   __compat_gid_t gid;
+   __compat_uid_t cuid;
+   __compat_gid_t cgid;
compat_mode_t   mode; 
unsigned short  seq;
unsigned short __pad1;
diff -ruNp linus/fs/compat.c linus-compat_uid_t/fs/compat.c
--- linus/fs/compat.c   2005-07-13 15:13:18.0 +1000
+++ linus-compat_uid_t/fs/compat.c  2005-07-13 16:26:29.0 +1000
@@ -720,14 +720,14 @@ compat_sys_io_submit(aio_context_t ctx_i
 struct compat_ncp_mount_data {
compat_int_t version;
compat_uint_t ncp_fd;
-   compat_uid_t mounted_uid;
+   __compat_uid_t mounted_uid;
compat_pid_t wdog_pid;
unsigned char mounted_vol[NCP_VOLNAME_LEN + 1];
compat_uint_t time_out;
compat_uint_t retry_count;
compat_uint_t flags;
-   compat_uid_t uid;
-   compat_gid_t gid;
+   __compat_uid_t uid;
+   __compat_gid_t gid;
compat_mode_t file_mode;
compat_mode_t dir_mode;
 };
@@ -784,9 +784,9 @@ static void *do_ncp_super_data_conv(void
 
 struct compat_smb_mount_data {
compat_int_t version;
-   compat_uid_t mounted_uid;
-   compat_uid_t uid;
-   compat_gid_t gid;
+   __compat_uid_t mounted_uid;
+   __compat_uid_t uid;
+   __compat_gid_t gid;
compat_mode_t file_mode;
compat_mode_t dir_mode;
 };
@@ -1808,8 +1808,8 @@ struct compat_nfsctl_export {
compat_dev_tex32_dev;
compat_ino_tex32_ino;
compat_int_tex32_flags;
-   compat_uid_tex32_anon_uid;
-   compat_gid_tex32_anon_gid;
+   __compat_uid_t  ex32_anon_uid;
+   __compat_gid_t  ex32_anon_gid;
 };
 
 struct compat_nfsctl_fdparm {
diff -ruNp linus/include/asm-ia64/compat.h 
linus-compat_uid_t/include/asm-ia64/compat.h
--- linus/include/asm-ia64/compat.h 2005-06-27 16:08:06.0 +1000
+++ linus-compat_uid_t/include/asm-ia64/compat.h2005-06-27 
17:40:08.0 +1000
@@ -13,10 +13,10 @@ typedef s32 compat_time_t;
 typedef s32compat_clock_t;
 typedef s32compat_key_t;
 typedef s32compat_pid_t;
-typedef u16compat_uid_t;
-typedef u16compat_gid_t;
-typedef u32compat_uid32_t;
-typedef u32compat_gid32_t;
+typedef u16__compat_uid_t;
+typedef u16__compat_gid_t;
+typedef u32__compat_uid32_t;
+typedef u32__compat_gid32_t;
 typedef u16compat_mode_t;
 typedef u32compat_ino_t;
 typedef u16compat_dev_t;
@@ -50,8 +50,8 @@ struct compat_stat {
compat_ino_tst_ino;
compat_mode_t   st_mode;
compat_nlink_t  st_nlink;
-   compat_uid_t

Re: RT and XFS

[hui]

On Fri, Jul 15, 2005 at 09:16:55AM -0700, Daniel Walker wrote:
> I don't agree with that. But of course I'm always speaking from a real
> time perspective . PI is expensive , but it won't always be. However, no
> one is forcing PI on anyone, even if I think it's good ..

It depends on what kind of PI under specific circumstances. In the general
kernel, it's really to be avoided at all costs since it's masking a general
contention problem at those places. In a formally provable worst case system
using priority ceiling emulation and stuff, PI really valuable. How a system
like the Linux kernel fits into that is a totally different story. General
purpose kernels using general purpose facilities don't.

That's how I see it.

bill

-
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: RT and XFS

[hui]

On Mon, Jul 18, 2005 at 02:10:31PM +0200, Esben Nielsen wrote:
> Unfortunately, one of the goals of the preempt-rt branch is to avoid
> altering too much code. Therefore the type semaphore can't be removed
> there. Therefore the name still lingers ... :-(

This is where you failed. You assumed that that person making the comment,
Christopher, in the first place didn't have his head up his ass in the
first place and was open to your end of the discussion.

bill

-
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: Regarding KDB for REDHAT9.0

[Fawad Lateef]

On 7/19/05, Keith Owens <[EMAIL PROTECTED]> wrote:
> 
> Sorry, not available.  RedHat do not want kdb so SGI do not do KDB
> patches against RedHat distributions.  Use SuSE instead, that has KDB
> built in.
> 

I want to add one more thing, you can compile your own kernel with KDB
patch applied  if u really want to use KDB on Redhat .. And I
think you can also try to apply patch of KDB for 2.4.20 on the Redhat
kenel, that might succeed if redhat havn't changed anything in the
files of 2.4.20 kernel in which KDB patches or make changes .


-- 
Fawad Lateef
-
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: [GIT PATCH] Remove devfs from 2.6.12-git

[Jim Crilly]

On 07/18/05 10:12:29PM +0200, Jan Engelhardt wrote:
> 
> Something's wondering me, though:
> FreeBSD "just" (5.0) introduced devfs, so either they are behind The Facts 
> (see udev FAQ), or devfs (anylinux/anybsd) is not so bad after all.

There's not much to wonder about here, the basic idea of devfs is a good
one which is why udev was written. The problems expressed on lkml about
devfs were with that specifically implementation, if a better
implementation had been merged originally udev might have never been
created. I really doubt FreeBSD took the Linux devfs code and integrated it
with their kernel, so the fact that FreeBSD is using a devfs now simply
means they like the idea of a dynamic /dev as well.

> 
> 
> 
> Jan Engelhardt

Jim.
-
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.12-rc2 and as-iosched

[Kenneth Parrish]

-=> [EMAIL PROTECTED] wrote to Kenneth Parrish <=-

 ax> ok, AS is definitely broken, it does an internal HZ <-> msec
 ax> conversion in the store/show functions as well. This should fix
 ax> it.
thank ya   :-)
-
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: repeated Oops on Kernel 2.6.12.2

[Jesper Juhl]

On 7/18/05, Parminder Chhabra <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I get repeated Oops messages on 2.6.12.2. I get the message on inserting a

Have you tested a more recent kernel like 2.6.13-rc3 or
2.6.13-rc3-git4 or 2.6.13-rc3-mm1 to see if the problem is already
solved?

> module that spawns a kernel thread to perform a task on a group of packets.

Perhaps you could provide the code for that module somewhere?

Sorry I can't be of more help.


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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: Regarding KDB for REDHAT9.0

[Keith Owens]

On Mon, 18 Jul 2005 11:29:39 +0530 (IST), 
Subbu <[EMAIL PROTECTED]> wrote:
> I have REDHAT 9.0 (kernel version 2.4.20-8) and i want to have KDB.
>please tell me which version of KDB i can use with redhat 9.0 and above
>mentioned kernel version.

Sorry, not available.  RedHat do not want kdb so SGI do not do KDB
patches against RedHat distributions.  Use SuSE instead, that has KDB
built in.

-
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: Fw: Oops in hidinput_hid_event

[Jesper Juhl]

On 7/19/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/18/05, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > I think this patch is rather obvious, so maybe I should ask Andrew to
> > apply it to -mm for now, to get some testing. Would that help to verify
> > it for acceptance?
> >
> > -- Pete
> >
> > Begin forwarded message:
> >
> > Date: Tue, 28 Jun 2005 15:00:23 -0700
> > From: Pete Zaitcev <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
> > Subject: Oops in hidinput_hid_event
> >
> > Hi, Vojtech:
> >
> > Someone reported a bug in Fedora, which runs a largely unmodified upstream
> > kernel in this area. Whenever the user hits a key which switches LED,
> > the system oopses. Here's a trace:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 00c8
> > EFLAGS: 00010006   (2.6.11-1.1369_FC4smp)
> > EIP is at hidinput_hid_event+0x2d/0x292
> > Call Trace:
> >  [] hid_process_event+0x57/0x5f
> >  [] hid_input_field+0x2a2/0x2ac
> >  [] hid_input_report+0x9e/0xb8
> >  [] hid_ctrl+0x14c/0x151
> >  [] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
> >  [] usb_hcd_giveback_urb+0x24/0x67
> >  [] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
> >  [] uhci_finish_completion+0x44/0x56 [uhci_hcd]
> >  [] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
> >  [] i8042_interrupt+0x121/0x234
> >  [] uhci_irq+0x47/0x10d [uhci_hcd]
> >
> > Full trace at
> >  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709
> >
> > Any ideas?
> >
> > By the way, it seems that I see a bug in hidinput_hid_event.
> > The check for NULL can never work, becaue >input
> > is nonzero at all times. How about this?
> >
> > --- linux-2.6.12/drivers/usb/input/hid-input.c  2005-06-21 
> > 12:58:47.0 -0700
> > +++ linux-2.6.12-lem/drivers/usb/input/hid-input.c  2005-06-28 
> > 14:57:22.0 -0700
> > @@ -397,11 +397,12 @@
> >
> >  void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, 
> > struct hid_usage *usage, __s32 value, struct pt_regs *regs)
> >  {
> > -   struct input_dev *input = >hidinput->input;
> > +   struct input_dev *input;
> > int *quirks = >quirks;
> >
> > -   if (!input)
> > +   if (!field->hidinput)
> 
> How about
>  if (!field || !field->hdinput)
> instead?
> 
> > return;
> > +   input = >hidinput->input;
> 
> Add a
>  if (!input)
>  return;
> check here?
> 
Ehh, I must have been sleeping, disregard this last bit...

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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: Fw: Oops in hidinput_hid_event

[Jesper Juhl]

On 7/18/05, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> I think this patch is rather obvious, so maybe I should ask Andrew to
> apply it to -mm for now, to get some testing. Would that help to verify
> it for acceptance?
> 
> -- Pete
> 
> Begin forwarded message:
> 
> Date: Tue, 28 Jun 2005 15:00:23 -0700
> From: Pete Zaitcev <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
> Subject: Oops in hidinput_hid_event
> 
> Hi, Vojtech:
> 
> Someone reported a bug in Fedora, which runs a largely unmodified upstream
> kernel in this area. Whenever the user hits a key which switches LED,
> the system oopses. Here's a trace:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00c8
> EFLAGS: 00010006   (2.6.11-1.1369_FC4smp)
> EIP is at hidinput_hid_event+0x2d/0x292
> Call Trace:
>  [] hid_process_event+0x57/0x5f
>  [] hid_input_field+0x2a2/0x2ac
>  [] hid_input_report+0x9e/0xb8
>  [] hid_ctrl+0x14c/0x151
>  [] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
>  [] usb_hcd_giveback_urb+0x24/0x67
>  [] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
>  [] uhci_finish_completion+0x44/0x56 [uhci_hcd]
>  [] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
>  [] i8042_interrupt+0x121/0x234
>  [] uhci_irq+0x47/0x10d [uhci_hcd]
> 
> Full trace at
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709
> 
> Any ideas?
> 
> By the way, it seems that I see a bug in hidinput_hid_event.
> The check for NULL can never work, becaue >input
> is nonzero at all times. How about this?
> 
> --- linux-2.6.12/drivers/usb/input/hid-input.c  2005-06-21 12:58:47.0 
> -0700
> +++ linux-2.6.12-lem/drivers/usb/input/hid-input.c  2005-06-28 
> 14:57:22.0 -0700
> @@ -397,11 +397,12 @@
> 
>  void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, 
> struct hid_usage *usage, __s32 value, struct pt_regs *regs)
>  {
> -   struct input_dev *input = >hidinput->input;
> +   struct input_dev *input;
> int *quirks = >quirks;
> 
> -   if (!input)
> +   if (!field->hidinput)

How about
 if (!field || !field->hdinput)
instead?

> return;
> +   input = >hidinput->input;

Add a 
 if (!input)
 return;
check here?

> 
> input_regs(input, regs);
> 
> 
> -- Pete

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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: how to be a kernel developer ?

[Jesper Juhl]

On 7/19/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/18/05, regatta <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > I want to join the Kernel community and help in developing Linux
> > kernel, I'm good in C,Perl and  not that good in C++
> >
> The kernel is written in (mainly) C and (a little bit of) asm, no C++ in 
> there.
> 
> > is there any How-To page in how to help or how to join ? since I want
> > to start in basic things
> >
> A few things you should do :
> 
[snip]

A few things I forgot to mention in the first mail.

You can also help out by testing the development kernels - they need
testing by as many people as possible, so start testing the -rc
kernels and the daily git snapshots as well as the -mm kernels. Test
if they build with your usual configuration, test if they build with
"allnoconfig", "allyesconfig", "allmodconfig" and perhaps a random
config or two. Test if they boot OK, if they run OK for a longer time,
etc.
When you find a problem you can try to fix the issue yourself and send
a patch to both the mailinglist and the person responsible for the
code in question. If you are unable to fix the problem yourself, then
send a detailed bugreport to the list and the person responsible for
the code.  Take a look at the REPORTING-BUGS file in the kernel source
dir and the Documentation/BUG-HUNTING file.

Helping to test pre-release kernels is a valuable effort. Run a new
kernel daily :-)

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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: how to be a kernel developer ?

[Jesper Juhl]

On 7/18/05, regatta <[EMAIL PROTECTED]> wrote:
> Hi
> 
> I want to join the Kernel community and help in developing Linux
> kernel, I'm good in C,Perl and  not that good in C++
> 
The kernel is written in (mainly) C and (a little bit of) asm, no C++ in there.

> is there any How-To page in how to help or how to join ? since I want
> to start in basic things
> 
A few things you should do : 

- Take a look in the Documentation/ directory in the kernel source,
you'll find lots of valuable information there.

- Go check out http://kernelnewbies.org/

- You may also find this online source browser useful (I know I do)
http://lxr.linux.no/

- Keep a link to a LKML archive in your bookmarks and search the
archives for answers whenever you have a question - chances are good
that whatever you want to ask has been asked before and answered in
depth on the list, so it'll be in the archives. Here's one LKML
archive you can use, it goes back a few years :
http://www.ussg.iu.edu/hypermail/linux/kernel/

- Subscribe to LKML and start reading the some of the threads. A lot
can be learned by reading the bugreports and solutions that pop up on
the list, there are also often discussions on ideas, implementation
details, debugging etc etc that can be valuable. So join the list and
start listening :)  ohh, and do read the lists FAQ at
http://www.tux.org/lkml/

- You may also want to join the Linux Kernel Janitors
http://janitor.kernelnewbies.org/ - they have a mailing list and a
nice TODO list of things that need doing - good place to pick a small
starting project from.

- You should also, most likely, invest in a few books on the kernel
and read them. I'd recommend these two as good ones to start with :
"Linux Kernel Development (2nd Edition), by Robert Love" and "Linux
Device Drivers (Third Edition), by Jonathan Corbet, Alessandro Rubini,
and Greg Kroah-Hartman".

- And most important of all, start reading the kernel source, and play
with the kernel source. Reading the source, making some changes and
then testing them and learning from the mistakes you make is a great
way to learn.


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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.12.3 ompilation errors with linux1394.org rev.1315

[Jesper Juhl]

On 7/18/05, art <[EMAIL PROTECTED]> wrote:
> 
> 2.6.12.3 ompilation errors with linux1394.org rev.1315
> 
> []$ make && make modules

That's redundant, "make" implicitly does "make modules", so just
running "make" will do.

> ..
> LD  drivers/ieee1394/built-in.o
>   CC [M]  drivers/ieee1394/ieee1394_core.o
> drivers/ieee1394/ieee1394_core.c: In function 'hpsbpkt_thread':
> drivers/ieee1394/ieee1394_core.c:1035: error: too few arguments to function 
> 'try_to_freeze'

try_to_freeze() used to take a single argument, it doesn't any more -
looks like someone forgot to teach that to ieee1394_core.c. It seems
to be fixed in 2.6.13-rc3 though, so try that one.


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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] pci_find_device --> pci_get_device

[Jiri Slaby]

The patch is for mixed files from all over the tree.

Kernel version: 2.6.13-rc3-git4

* This patch removes from kernel tree pci_find_device and changes
it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
count of the variable.
* Next, there are some (about 10 or so) gcc warning problems (i. e.
variable may be unitialized) solutions, which were around code with old
pci_find_device.
* Some code was unpretty, or ugly, so the patch provides more readable
code, in some cases.
* Marks the function as deprecated in pci.h

The patch is here, (because of its size -- about 120 KiB):
http://www.fi.muni.cz/~xslaby/lnx/lnx-pci_find-2.6.13-r3g4.patch
and its bzipped version, if you want (about 25 KiB):
http://www.fi.muni.cz/~xslaby/lnx/lnx-pci_find-2.6.13-r3g4.patch.bz2

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~  [EMAIL PROTECTED]  ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10

-
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: [Ext2-devel] [RFC] [PATCH 2/4]delayed allocation for ext3

[Badari Pulavarty]

On Sun, 2005-07-17 at 19:47 -0600, Andreas Dilger wrote:
> On Jul 17, 2005  10:40 -0700, Mingming Cao wrote:
> > @@ -373,6 +373,7 @@ struct ext3_inode {
> >  #define EXT3_MOUNT_BARRIER 0x2 /* Use block barriers */
> >  #define EXT3_MOUNT_NOBH0x4 /* No bufferheads */
> >  #define EXT3_MOUNT_QUOTA   0x8 /* Some quota option set */
> > + #define EXT3_MOUNT_DELAYED_ALLOC  0xC /* Delayed Allocation */
> 
> This doesn't make sense.  DELAYED_ALLOC == QUOTA | NOBH?

My fault. I will fix it.

> 
> > + {Opt_delayed_alloc, "delalloc"},
> 
> Is this a replacement for Alex's delalloc code?  We also use delalloc for
> that code and if they are not interchangeable it will cause confusion
> about which one is in use.
> 

Well, basically "delalloc" concept is same - whether we use it on
current ext3 layout or with new extent layout doesn't matter.


> > + if (test_opt(sb, DELAYED_ALLOC)) {
> > + if (!(test_opt(sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)) 
> > {
> > + printk(KERN_WARNING "EXT3-fs: Ignoring delall option 
> > - "
> > + "its supported only with writeback mode\n");
> 
> Should be "ignoring delalloc option".

Yep.

Thanks,
Badari



-
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] no more need to check for NULL before calls to crypto_free_tfm

[Jesper Juhl]

On 7/18/05, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 17, 2005 at 12:32:27AM +0200, Jesper Juhl wrote:
> >
> > --- linux-2.6.13-rc3-orig/drivers/block/cryptoloop.c  2005-06-17 
> > 21:48:29.0 +0200
> > +++ linux-2.6.13-rc3/drivers/block/cryptoloop.c   2005-07-16 
> > 23:35:55.0 +0200
> > @@ -227,14 +227,14 @@ cryptoloop_ioctl(struct loop_device *lo,
> >  static int
> >  cryptoloop_release(struct loop_device *lo)
> >  {
> > - struct crypto_tfm *tfm = (struct crypto_tfm *) lo->key_data;
> > - if (tfm != NULL) {
> > - crypto_free_tfm(tfm);
> > - lo->key_data = NULL;
> > - return 0;
> > + struct crypto_tfm *tfm = lo->key_data;
> > + if (!tfm) {
> > + printk(KERN_ERR "cryptoloop_release(): tfm == NULL?\n");
> > + return -EINVAL;
> >   }
> > - printk(KERN_ERR "cryptoloop_release(): tfm == NULL?\n");
> > - return -EINVAL;
> > + crypto_free_tfm(tfm);
> > + lo->key_data = NULL;
> > + return 0;
> >  }
> 
> This change looks rather pointless.
> 
Hmm, I guess you're right. Dunno why I reordered that, but you are
right, it's pretty pointless. Except for getting rid of the cast, that
makes sense, it's superfluous so it should go away...

> The rest of the patch looks good.
> 
> Thanks,

You're welcome. Thank you for reviewing it.


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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/

drivers/w1/w1_int.c compile error with NET=n

[Adrian Bunk]

I'm seeing the following compile error in 2.6.13-rc3-mm1 (but it doesn't 
seem to be specific to -mm) with CONFIG_NET=n:

<--  snip  -->

...
  LD  .tmp_vmlinux1
drivers/built-in.o: In function `w1_alloc_dev':
w1_int.c:(.text+0x65d81f): undefined reference to `netlink_kernel_create'
w1_int.c:(.text+0x65d881): undefined reference to `sock_release'
drivers/built-in.o: In function `w1_free_dev':
w1_int.c:(.text+0x65d8e9): undefined reference to `sock_release'
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->



cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-
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] QLA2xxx FW_LOADER Kconfig issue results in undefined symbols

[Adrian Bunk]

On Mon, Jul 18, 2005 at 02:23:57PM -0500, Erik Jacobson wrote:
> I hit a small problem (first observed in 2.6.13-rc3-mm1) that resulted in
> my kernels no longer building because of undefined references to 
> request_firmware and release_firmware.
> 
> After a little research, I found that the QLA stuff requires CONFIG_FW_LOADER.
> 
> I was using the sn2_defconfig as a starting point for my config file. 
> This config file compiles some of the QLA2xxx drivers statically.
> By default, CONFIG_FW_LOADER is set to "m" and not "y".
> 
> So this small change should ensure CONFIG_FW_LOADER is set properly.
> 
> Perhaps there are better ways to do this?
>...
> --- 2.6-akpm-rc-mm-orig/drivers/scsi/qla2xxx/Kconfig  2005-07-15 
> 10:58:54.316985000 -0500
> +++ 2.6-akpm-rc-mm/drivers/scsi/qla2xxx/Kconfig   2005-07-18 
> 14:03:37.888758336 -0500
> @@ -3,6 +3,7 @@
>   default (SCSI && PCI)
>   depends on SCSI && PCI
>   select SCSI_FC_ATTRS
> + select FW_LOADER
>  
>  config SCSI_QLA21XX
>   tristate "QLogic ISP2100 host adapter family support"
>...
 
I have to resend my patch for this issue that didn't make it through the 
linux-kernel filters.

Your patch enables FW_LOADER for everyone with (SCSI && PCI) since is a 
not user-visible option that is enabled then.

The correct solution my patch does is to add a "select FW_LOADER" to 
every single of the driver options below.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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: Promise TX4200 support?

[Daniel Drake]

Hi Martin,

Martin Povolný wrote:

We are succesfully running patched sata_promise with 3 disks in a
raid5/raid1 setup. (Patched against ubuntu linux-image 2.6.11-1-686
package.)


Could you please either send in your patch, or tell me which board_ setting 
(2037x/20319/20619) the device ID table should include so I can write submit 
one myself.



'lspci -v' says:

02:02.0 RAID bus controller: Promise Technology, Inc.: Unknown device
3519 (rev 02)
Subsystem: Promise Technology, Inc.: Unknown device 3519
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 18
I/O ports at dc00 [size=128]
I/O ports at d800 [size=256]
Memory at feaff000 (32-bit, non-prefetchable) [size=4K]
Memory at feac (32-bit, non-prefetchable) [size=128K]
Expansion ROM at feae [disabled] [size=64K]
Capabilities: [60] Power Management version 2


Thanks,
Daniel
-
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: [GIT PATCH] Remove devfs from 2.6.12-git

[Daniel Phillips]

On Tuesday 19 July 2005 06:12, Jan Engelhardt wrote:
> What is more news to me:
> ( http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ )
> Q: Why was devfs marked OBSOLETE if udev is not finished yet?
> A: To quote Al Viro (Linux VFS kernel maintainer):
> ==> - the devfs maintainer/author disappeared and stoped maintaining the
> code

Chased out by the same Al Viro, more like it.  Not that I like devfs at all, 
but it's a shame to see such revisionism in an otherwise respectable 
document.

Regards,

Daniel
-
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/

[RFC][UPDATE PATCH 2/4] human-time soft-timer core changes

[Nishanth Aravamudan]

On 14.07.2005 [13:40:11 -0700], Nishanth Aravamudan wrote:
> From: Nishanth Aravamudan <[EMAIL PROTECTED]>
> 
> Description: The core revision to the soft-timer subsystem to divorce it
> from the timer interrupt in software, i.e. jiffies. Instead, use
> getnstimeofday() (via do_monotonic_clock()) as the basis for addition
> and expiration of timers. Add a new unit, the timerinterval, which is
> a 2^TIMERINTERVAL_BITS nanoseconds in length. The converted value in
> timerintervals is used where we would have used the timer's expires
> member before. Add set_timer_nsecs() and set_timer_nsecs_on() functions
> to directly request nanosecond delays. These functions replace
> add_timer(), mod_timer() and add_timer_on().
> 
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>

Sigh, one version of my development patches removed the export of
mod_timer(). Of course, I forgot to revert that hunk before sending it
out. If anyone (maybe not likely) is testing out these patches, please
use this version.

Thanks,
Nish

---

 include/linux/time.h  |1 
 include/linux/timer.h |   27 +-
 kernel/time.c |   18 
 kernel/timer.c|  215 +-
 4 files changed, 221 insertions(+), 40 deletions(-)

diff -urpN 2.6.13-rc3-base/include/linux/time.h 
2.6.13-rc3-dev/include/linux/time.h
--- 2.6.13-rc3-base/include/linux/time.h2005-03-01 23:38:12.0 
-0800
+++ 2.6.13-rc3-dev/include/linux/time.h 2005-07-14 12:44:40.0 -0700
@@ -103,6 +103,7 @@ struct itimerval;
 extern int do_setitimer(int which, struct itimerval *value, struct itimerval 
*ovalue);
 extern int do_getitimer(int which, struct itimerval *value);
 extern void getnstimeofday (struct timespec *tv);
+extern u64 do_monotonic_clock(void);
 
 extern struct timespec timespec_trunc(struct timespec t, unsigned gran);
 
diff -urpN 2.6.13-rc3-base/include/linux/timer.h 
2.6.13-rc3-dev/include/linux/timer.h
--- 2.6.13-rc3-base/include/linux/timer.h   2005-07-13 15:52:14.0 
-0700
+++ 2.6.13-rc3-dev/include/linux/timer.h2005-07-14 12:44:40.0 
-0700
@@ -11,6 +11,7 @@ struct timer_base_s;
 struct timer_list {
struct list_head entry;
unsigned long expires;
+   u64 expires_nsecs;
 
unsigned long magic;
 
@@ -27,6 +28,7 @@ extern struct timer_base_s __init_timer_
 #define TIMER_INITIALIZER(_function, _expires, _data) {\
.function = (_function),\
.expires = (_expires),  \
+   .expires_nsecs = 0, \
.data = (_data),\
.base = &__init_timer_base, \
.magic = TIMER_MAGIC,   \
@@ -51,30 +53,15 @@ static inline int timer_pending(const st
 
 extern void add_timer_on(struct timer_list *timer, int cpu);
 extern int del_timer(struct timer_list * timer);
-extern int __mod_timer(struct timer_list *timer, unsigned long expires);
+extern int __mod_timer(struct timer_list *timer);
 extern int mod_timer(struct timer_list *timer, unsigned long expires);
+extern void add_timer(struct timer_list *timer);
+extern int set_timer_nsecs(struct timer_list *timer, u64 expires_nsecs);
+extern void set_timer_on_nsecs(struct timer_list *timer, u64 expires_nsecs,
+   int cpu);
 
 extern unsigned long next_timer_interrupt(void);
 
-/***
- * add_timer - start a timer
- * @timer: the timer to be added
- *
- * The kernel will do a ->function(->data) callback from the
- * timer interrupt at the ->expired point in the future. The
- * current time is 'jiffies'.
- *
- * The timer's ->expired, ->function (and if the handler uses it, ->data)
- * fields must be set prior calling this function.
- *
- * Timers with an ->expired field in the past will be executed in the next
- * timer tick.
- */
-static inline void add_timer(struct timer_list * timer)
-{
-   __mod_timer(timer, timer->expires);
-}
-
 #ifdef CONFIG_SMP
   extern int try_to_del_timer_sync(struct timer_list *timer);
   extern int del_timer_sync(struct timer_list *timer);
diff -urpN 2.6.13-rc3-base/kernel/time.c 2.6.13-rc3-dev/kernel/time.c
--- 2.6.13-rc3-base/kernel/time.c   2005-07-13 15:51:57.0 -0700
+++ 2.6.13-rc3-dev/kernel/time.c2005-07-14 12:44:40.0 -0700
@@ -589,3 +589,21 @@ EXPORT_SYMBOL(get_jiffies_64);
 #endif
 
 EXPORT_SYMBOL(jiffies);
+
+u64 do_monotonic_clock(void)
+{
+   struct timespec now, now_w2m;
+   unsigned long seq;
+
+   getnstimeofday();
+
+   do {
+   seq = read_seqbegin(_lock);
+   now_w2m = wall_to_monotonic;
+   } while (read_seqretry(_lock, seq));
+
+   return (u64)(now.tv_sec + now_w2m.tv_sec) * NSEC_PER_SEC +
+   (now.tv_nsec + now_w2m.tv_nsec);
+}
+

[PATCH] reiserfs: fix deadlock in inode creation failure path w/ default ACL

[Jeff Mahoney]

 reiserfs_new_inode() can call iput() with the xattr lock held. This will
 cause a deadlock to occur when reiserfs_delete_xattrs() is called to
 clean up.

 The following patch releases the lock and reacquires it after the iput. This
 is safe because interaction with xattrs is complete, and the relock is just
 to balance out the release in the caller.

 The locking needs some reworking to be more sane, but that's more intrusive
 and I was just looking to fix this bug.

Signed-off-by: Jeff Mahoney <[EMAIL PROTECTED]>

diff -ruNpX dontdiff linux-2.6.13-rc3/fs/reiserfs/inode.c 
linux-2.6.13-rc3.errors/fs/reiserfs/inode.c
--- linux-2.6.13-rc3.1/fs/reiserfs/inode.c  2005-07-14 19:43:14.0 
-0400
+++ linux-2.6.13-rc3.2/fs/reiserfs/inode.c  2005-07-18 15:21:32.0 
-0400
@@ -1980,7 +1978,17 @@ int reiserfs_new_inode(struct reiserfs_t
   out_inserted_sd:
inode->i_nlink = 0;
th->t_trans_id = 0; /* so the caller can't use this handle later */
-   iput(inode);
+   
+   /* If we were inheriting an ACL, we need to release the lock so that
+* iput doesn't deadlock in reiserfs_delete_xattrs. The locking
+* code really needs to be reworked, but this will take care of it 
+* for now. -jeffm */
+   if (REISERFS_I(dir)->i_acl_default) {
+   reiserfs_write_unlock_xattrs(dir->i_sb);
+   iput(inode);
+   reiserfs_write_lock_xattrs(dir->i_sb);
+   } else
+   iput(inode);
return err;
 }
 
-- 
Jeff Mahoney
SuSE Labs
-
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] QLA2xxx FW_LOADER Kconfig issue results in undefined symbols

[Erik Jacobson]

I hit a small problem (first observed in 2.6.13-rc3-mm1) that resulted in
my kernels no longer building because of undefined references to 
request_firmware and release_firmware.

After a little research, I found that the QLA stuff requires CONFIG_FW_LOADER.

I was using the sn2_defconfig as a starting point for my config file. 
This config file compiles some of the QLA2xxx drivers statically.
By default, CONFIG_FW_LOADER is set to "m" and not "y".

So this small change should ensure CONFIG_FW_LOADER is set properly.

Perhaps there are better ways to do this?

Signed-off-by: Erik Jacobson <[EMAIL PROTECTED]>

---

 Kconfig |1 +
 1 files changed, 1 insertion(+)


diff -Naru 2.6-akpm-rc-mm-orig/drivers/scsi/qla2xxx/Kconfig 
2.6-akpm-rc-mm/drivers/scsi/qla2xxx/Kconfig
--- 2.6-akpm-rc-mm-orig/drivers/scsi/qla2xxx/Kconfig2005-07-15 
10:58:54.316985000 -0500
+++ 2.6-akpm-rc-mm/drivers/scsi/qla2xxx/Kconfig 2005-07-18 14:03:37.888758336 
-0500
@@ -3,6 +3,7 @@
default (SCSI && PCI)
depends on SCSI && PCI
select SCSI_FC_ATTRS
+   select FW_LOADER
 
 config SCSI_QLA21XX
tristate "QLogic ISP2100 host adapter family support"

--
Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota
-
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: Avoiding BIGMEM support programatically.

[Fawad Lateef]

On 7/18/05, vamsi krishna <[EMAIL PROTECTED]> wrote:
> Hello All,
> 
> I have a program working fine on a 2.6.xx-smp kernel, and the program
> crashes on the same version kernel with bigmem i.e (2.6.xxx-bigmem).
> 

What is your program ??? what it is doing ??? Can u explain ?? or send
some code portion ?? b/c the BIGMEM kernel and smp/normal kenel has
only a difference of HIGHMEM64G which allows system/kernel on x86 to
use physical memory upto 64GB . and enabling this creates
little-bit overhead on the kernel, but I don't think it will effect
the working of most of the kernel modules ..

> I also found that for a same executable on bigmem kernel the virtual
> address's of '&_start' and '&_etext', seem to vary in every new run.
> 

I don't know abt this, so can't say any thing 

> Is there any way I can avoid the kernel's bigmem virtual address
> mapping programatically? and still run the program on a bigmem kernel?
> 

I think this can be done through specifying GFP_ATOMIC flag in the
memory allocation function, so that it will use ZONE_NORMAL of the
kernel ... (if i m wrong, then plzz do correct me)

-- 
Fawad Lateef
-
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: Why is 2.6.12.2 less stable on my laptop than 2.6.10?

[Mark Gross]

On Friday 15 July 2005 16:14, Rik van Riel wrote:
> On Fri, 15 Jul 2005, Mark Gross wrote:
> > What would be wrong in expecting the folks making the driver changes
> > have some story on how they are validating there changes don't break
> > existing working hardware?  I could probly be accomplished in open
> > source with subsystem testing volenteers.
>
> Are you volunteering ?

I am not volunteering.  That last sentence was meant to say "It could 
probubly..."

I'm just poking at a process change that would include a more formal 
validation / testing phase as part of getting change into the stable tree.  I 
don't have any silver bullets.

-- 
--mgross
BTW: This may or may not be the opinion of my employer, more likely not.  

-
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.6] remove PCI_BRIDGE_CTL_VGA handling from setup-bus.c

[Grant Grundler]

On Thu, Jul 14, 2005 at 02:53:27PM +0100, Russell King wrote:
> On Thu, Jul 14, 2005 at 03:53:44PM +0400, Ivan Kokshaysky wrote:
> > The setup-bus code doesn't work correctly for configurations
> > with more than one display adapter in the same PCI domain.
> > This stuff actually is a leftover of an early 2.4 PCI setup code
> > and apparently it stopped working after some "bridge_ctl" changes.
> > So the best thing we can do is just to remove it and rely on the fact
> > that any firmware *has* to configure VGA port forwarding for the boot
> > display device properly.
> 
> What happens when there is no firmware?

I helped test/add bridge_ctl patch but PARISC general does NOT
support VGA at this time.

> I'm sure this code would not have been added had there not been a reason
> for it.  Do we know why it was added?

It was a replacement for the previous hacks and should represent essentially
the same functionality. I suspect we just didn't care about (or test)
multiheaded gfx at the time. Certainly not on parisc. This was in 2000/2001
timeframe originally.

grant
-
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/

RT-V0.7.51-31 vs ntpd, 1 to nothin so far

[Gene Heskett]

Hi Ingo;

I just built 51-31, mode 4, and although I spent an hour putting in 
debug printouts in /etc/init.d/ntpd, I couldn't make it work, and 
the /var/log/ntpd.log is being flooded with "bad file descriptor" 
messages.

So I'm back on 51-30 in mode 3 for the time being so tvtime works.
 
-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
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: [Fastboot] [RFC/PATCH 1/17][kexec-tools-1.101] vmlinux parameter segment stomping fix

[Eric W. Biederman]

My apologies for taking so long to look at these patches.

I agree there is an issue here, but large parts of this
we need to address kernel side.  If the parameter buffer is allocated
after the kernel there is no guarantee that it will be addressable
from the kernels early page table so this fix will not work.
As for the practical problem it addresses it looks like we simply
need to increase the size of the kernel's bss segment so we don't
stop things.

Problem agreed upon patch rejected.

Eric

Vivek Goyal <[EMAIL PROTECTED]> writes:

> During loading of panic kernel(vmlinux), it was found that on some systems,
> parameter segment was being stomped over by kernel. This was resulting in 
> corruption of e820 memory map and leading to boot memory allocator
> initialization failures while booting into new kernel. This patch fixes the
> problem by loading the parameter segment beyond alrady loaded kernel image
> and setup code. A 64K buffer has been provided to avoid any stomping by
> kernel.

>
> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
> ---
>
>  kexec-tools-1.101-root/kexec/arch/i386/kexec-elf-x86.c |   16 
> ++--
>  1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff -puN 
> kexec/arch/i386/kexec-elf-x86.c~kexec-tools-vmlinux-parameter-segment-stomping-fix
>  kexec/arch/i386/kexec-elf-x86.c
> --- 
> kexec-tools-1.101/kexec/arch/i386/kexec-elf-x86.c~kexec-tools-vmlinux-parameter-segment-stomping-fix
>   2005-03-21 16:43:50.0 +0530
> +++ kexec-tools-1.101-root/kexec/arch/i386/kexec-elf-x86.c2005-03-21 
> 16:43:50.0 +0530
> @@ -199,15 +199,27 @@ int elf_x86_load(int argc, char **argv, 
>   }
>   else if (arg_style == ARG_STYLE_LINUX) {
>   struct x86_linux_faked_param_header *hdr;
> - unsigned long param_base;
> + unsigned long param_base, min_param_base = 0;
>   const unsigned char *ramdisk_buf;
>   off_t ramdisk_length;
>   struct entry32_regs regs;
> + int i;
>  
>   /* Get the linux parameter header */
>   hdr = xmalloc(sizeof(*hdr));
> + /* Add parameter segment beyond already loaded segments, so that
> +  * it does not get stomped by kernel. */
> + for (i = 0; i < info->nr_segments; i++) {
> + unsigned long temp;
> + temp = (unsigned long) info->segment[i].mem +
> + info->segment[i].memsz;
> + if (temp > min_param_base)
> + min_param_base =  temp;
> + }
> + /* 64K of buffer to keep enough distance from kernel. */
> + min_param_base += 64*1024;
>   param_base = add_buffer(info, hdr, sizeof(*hdr), sizeof(*hdr),
> - 16, 0, max_addr, 1);
> + 16, min_param_base, max_addr, 1);
>  
>   /* Initialize the parameter header */
>   memset(hdr, 0, sizeof(*hdr));
> _
> ___
> fastboot mailing list
> [EMAIL PROTECTED]
> http://lists.osdl.org/mailman/listinfo/fastboot
-
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/

Promise TX4200 support?

[Daniel Drake]

Hi,

I recieved an email from someone claiming to be stuck with Linux 2.4, due to 
relying on a Promise TX4200 disk controller (using the fdsata driver from 
promise's website, which is 2.4-only):


:01:09.0 RAID bus controller: Promise Technology, Inc.: Unknown device 
3519 (rev 02)

Subsystem: Promise Technology, Inc.: Unknown device 3519
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 9
I/O ports at dc00 [size=128]
I/O ports at d800 [size=256]
Memory at ff8ff000 (32-bit, non-prefetchable) [size=4K]
Memory at ff8c (32-bit, non-prefetchable) [size=128K]
Expansion ROM at ff8e [disabled] [size=64K]
Capabilities: [60] Power Management version 2

What is the status of this on 2.6? I found a blank changeset (??) in the mail 
below, from 24th May:


Jeff Garzik wrote:
> Please pull the 'new-ids' branch from
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>
> This add new PCI ids to some SATA drivers.

> commit 37c15447c565ab458ee3778e198d08f4041caa99
> tree 2eda289903e3bf19eebce7d5f9aaed2240a02479
> parent 9422e59ddf6cae68e46d7a2c3afe1ce4e739d3eb
> author Martin Povolny <[EMAIL PROTECTED]> Mon, 16 May 2005 02:41:00 
-0400

> committer Jeff Garzik <[EMAIL PROTECTED]> Mon, 16 May 2005 02:41:00 -0400
>
> [PATCH] sata_promise: new PCI ID for TX4200
>
> [note - blank changeset]
>

Was this accidently removed, or is the sata_promise driver actually 
incompatible with this hardware?


Thanks,
Daniel

-
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: Promise TX4200 support?

[Martin Povolný]

Daniel Drake wrote:
> Hi,
> 
> I recieved an email from someone claiming to be stuck with Linux 2.4,
> due to relying on a Promise TX4200 disk controller (using the fdsata
> driver from promise's website, which is 2.4-only):
> 
> :01:09.0 RAID bus controller: Promise Technology, Inc.: Unknown
> device 3519 (rev 02)
> Subsystem: Promise Technology, Inc.: Unknown device 3519
> Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 9
> I/O ports at dc00 [size=128]
> I/O ports at d800 [size=256]
> Memory at ff8ff000 (32-bit, non-prefetchable) [size=4K]
> Memory at ff8c (32-bit, non-prefetchable) [size=128K]
> Expansion ROM at ff8e [disabled] [size=64K]
> Capabilities: [60] Power Management version 2
> 
> What is the status of this on 2.6? I found a blank changeset (??) in the
> mail below, from 24th May:
> 
> Jeff Garzik wrote:
>> Please pull the 'new-ids' branch from
>>
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>>
>> This add new PCI ids to some SATA drivers.
> 
>> commit 37c15447c565ab458ee3778e198d08f4041caa99
>> tree 2eda289903e3bf19eebce7d5f9aaed2240a02479
>> parent 9422e59ddf6cae68e46d7a2c3afe1ce4e739d3eb
>> author Martin Povolny <[EMAIL PROTECTED]> Mon, 16 May 2005
> 02:41:00 -0400
>> committer Jeff Garzik <[EMAIL PROTECTED]> Mon, 16 May 2005 02:41:00 -0400
>>
>> [PATCH] sata_promise: new PCI ID for TX4200
>>
>> [note - blank changeset]
>>
> 
> Was this accidently removed, or is the sata_promise driver actually
> incompatible with this hardware?
> 

We are succesfully running patched sata_promise with 3 disks in a
raid5/raid1 setup. (Patched against ubuntu linux-image 2.6.11-1-686
package.)

# check_partitions
disk: [8.0] => '/dev/sda', 279.4 GB
 1 : /dev/sda1 : Linux raid autodetect (  55 MB)
 2 : /dev/sda2 : Linux raid autodetect (  285640 MB)
 3 : /dev/sda3 : Linux swap( 486 MB)
disk: [8.16] => '/dev/sdb', 279.4 GB
 1 : /dev/sdb1 : Linux raid autodetect (  55 MB)
 2 : /dev/sdb2 : Linux raid autodetect (  285640 MB)
 3 : /dev/sdb3 : Linux swap( 486 MB)
disk: [8.32] => '/dev/sdc', 279.4 GB
 1 : /dev/sdc1 : Linux raid autodetect (  55 MB)
 2 : /dev/sdc2 : Linux raid autodetect (  285640 MB)
 3 : /dev/sdc3 : Linux swap( 486 MB)
disk: [9.0] => '/dev/md',
 0 : /dev/md0  : raid1 (  55 MB)
uuid: db3bdcf4:3e4774c7:b2541959:eeef67e0
0 active sync   /dev/sda1
1 active sync   /dev/sdb1
2 active sync   /dev/sdc1
 1 : /dev/md1  : raid5 (  571280 MB)
uuid: b9562e24:8a095e31:40702712:19009a40
0 active sync   /dev/sda2
1 active sync   /dev/sdb2
2 active sync   /dev/sdc2

'lspci -v' says:

02:02.0 RAID bus controller: Promise Technology, Inc.: Unknown device
3519 (rev 02)
Subsystem: Promise Technology, Inc.: Unknown device 3519
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 18
I/O ports at dc00 [size=128]
I/O ports at d800 [size=256]
Memory at feaff000 (32-bit, non-prefetchable) [size=4K]
Memory at feac (32-bit, non-prefetchable) [size=128K]
Expansion ROM at feae [disabled] [size=64K]
Capabilities: [60] Power Management version 2

No problems at all.

Regards,

-- 
Mgr. Martin Povolný, soLNet, s.r.o.,
+42014458, [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] MMC host class

[Russell King]

On Fri, Jul 15, 2005 at 10:21:43PM +0200, Pierre Ossman wrote:
> Russell King wrote:
> >Also note that since we have a class_dev, the mmc_host 'dev' field can
> >be removed.  However, we'll probably have to update the host drivers
> >to do this, so it should be a separate patch.
> 
> I believe there's a bit of abstraction to be gained from not poking
> around inside the class_dev struct in too many places. It's not like
> we're wasting any large amounts of memory.

I still don't like the needless duplication.  How about doing it this
way (see the attached patch.)

Note: I also intend to move MMC over to using an IDR for the host
numbers, which is why we need to setup the name at registration
time, not allocation time.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -x 
.git orig/drivers/mmc/mmc.c linux/drivers/mmc/mmc.c
--- orig/drivers/mmc/mmc.c  Sun Apr 24 21:02:15 2005
+++ linux/drivers/mmc/mmc.c Mon Jul 18 15:24:52 2005
@@ -361,7 +361,7 @@ static void mmc_decode_cid(struct mmc_ca
 
default:
printk("%s: card has unknown MMCA version %d\n",
-   card->host->host_name, card->csd.mmca_vsn);
+   mmc_hostname(card->host), card->csd.mmca_vsn);
mmc_card_set_bad(card);
break;
}
@@ -383,7 +383,7 @@ static void mmc_decode_csd(struct mmc_ca
csd_struct = UNSTUFF_BITS(resp, 126, 2);
if (csd_struct != 1 && csd_struct != 2) {
printk("%s: unrecognised CSD structure version %d\n",
-   card->host->host_name, csd_struct);
+   mmc_hostname(card->host), csd_struct);
mmc_card_set_bad(card);
return;
}
@@ -551,7 +551,7 @@ static void mmc_discover_cards(struct mm
}
if (err != MMC_ERR_NONE) {
printk(KERN_ERR "%s: error requesting CID: %d\n",
-   host->host_name, err);
+   mmc_hostname(host), err);
break;
}
 
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -x 
.git orig/drivers/mmc/mmc_sysfs.c linux/drivers/mmc/mmc_sysfs.c
--- orig/drivers/mmc/mmc_sysfs.cTue Jun 21 07:04:35 2005
+++ linux/drivers/mmc/mmc_sysfs.c   Mon Jul 18 15:25:07 2005
@@ -206,7 +206,7 @@ void mmc_init_card(struct mmc_card *card
 int mmc_register_card(struct mmc_card *card)
 {
snprintf(card->dev.bus_id, sizeof(card->dev.bus_id),
-"%s:%04x", card->host->host_name, card->rca);
+"%s:%04x", mmc_hostname(card->host), card->rca);
 
return device_add(>dev);
 }
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -x 
.git orig/drivers/mmc/mmci.c linux/drivers/mmc/mmci.c
--- orig/drivers/mmc/mmci.c Sat Jul  2 22:27:45 2005
+++ linux/drivers/mmc/mmci.cMon Jul 18 15:25:32 2005
@@ -34,7 +34,7 @@
 
 #ifdef CONFIG_MMC_DEBUG
 #define DBG(host,fmt,args...)  \
-   pr_debug("%s: %s: " fmt, host->mmc->host_name, __func__ , args)
+   pr_debug("%s: %s: " fmt, mmc_hostname(host->mmc), __func__ , args)
 #else
 #define DBG(host,fmt,args...)  do { } while (0)
 #endif
@@ -541,7 +541,7 @@ static int mmci_probe(struct amba_device
mmc_add_host(mmc);
 
printk(KERN_INFO "%s: MMCI rev %x cfg %02x at 0x%08lx irq %d,%d\n",
-   mmc->host_name, amba_rev(dev), amba_config(dev),
+   mmc_hostname(mmc), amba_rev(dev), amba_config(dev),
dev->res.start, dev->irq[0], dev->irq[1]);
 
init_timer(>timer);
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -x 
.git orig/drivers/mmc/wbsd.c linux/drivers/mmc/wbsd.c
--- orig/drivers/mmc/wbsd.c Sat Jul  2 22:27:45 2005
+++ linux/drivers/mmc/wbsd.cMon Jul 18 15:25:48 2005
@@ -1796,7 +1796,7 @@ static int __devinit wbsd_init(struct de

mmc_add_host(mmc);
 
-   printk(KERN_INFO "%s: W83L51xD", mmc->host_name);
+   printk(KERN_INFO "%s: W83L51xD", mmc_hostname(mmc));
if (host->chip_id != 0)
printk(" id %x", (int)host->chip_id);
printk(" at 0x%x irq %d", (int)host->base, (int)host->irq);
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -x 
.git orig/include/linux/mmc/host.h linux/include/linux/mmc/host.h
--- orig/include/linux/mmc/host.h   Sun Apr 24 21:06:29 2005
+++ linux/include/linux/mmc/host.h  Mon Jul 18 15:26:55 2005
@@ -97,6 +97,7 @@ extern void mmc_free_host(struct mmc_hos
 
 #define mmc_priv(x)((void *)((x) + 1))
 #define mmc_dev(x) ((x)->dev)
+#define mmc_hostname(x)((x)->host_name)
 
 extern int mmc_suspend_host(struct mmc_host *, pm_message_t);
 extern int mmc_resume_host(struct mmc_host *);
diff -u linux/drivers/mmc/mmc.c 

Fw: Oops in hidinput_hid_event

[Pete Zaitcev]

I think this patch is rather obvious, so maybe I should ask Andrew to
apply it to -mm for now, to get some testing. Would that help to verify
it for acceptance?

-- Pete

Begin forwarded message:

Date: Tue, 28 Jun 2005 15:00:23 -0700
From: Pete Zaitcev <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
Subject: Oops in hidinput_hid_event

Hi, Vojtech:

Someone reported a bug in Fedora, which runs a largely unmodified upstream
kernel in this area. Whenever the user hits a key which switches LED,
the system oopses. Here's a trace:

Unable to handle kernel NULL pointer dereference at virtual address 00c8
EFLAGS: 00010006   (2.6.11-1.1369_FC4smp)
EIP is at hidinput_hid_event+0x2d/0x292   
Call Trace:   
 [] hid_process_event+0x57/0x5f
 [] hid_input_field+0x2a2/0x2ac
 [] hid_input_report+0x9e/0xb8
 [] hid_ctrl+0x14c/0x151
 [] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
 [] usb_hcd_giveback_urb+0x24/0x67
 [] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
 [] uhci_finish_completion+0x44/0x56 [uhci_hcd]
 [] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
 [] i8042_interrupt+0x121/0x234
 [] uhci_irq+0x47/0x10d [uhci_hcd]

Full trace at
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709

Any ideas?

By the way, it seems that I see a bug in hidinput_hid_event.
The check for NULL can never work, becaue >input
is nonzero at all times. How about this?

--- linux-2.6.12/drivers/usb/input/hid-input.c  2005-06-21 12:58:47.0 
-0700
+++ linux-2.6.12-lem/drivers/usb/input/hid-input.c  2005-06-28 
14:57:22.0 -0700
@@ -397,11 +397,12 @@
 
 void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, 
struct hid_usage *usage, __s32 value, struct pt_regs *regs)
 {
-   struct input_dev *input = >hidinput->input;
+   struct input_dev *input;
int *quirks = >quirks;
 
-   if (!input)
+   if (!field->hidinput)
return;
+   input = >hidinput->input;
 
input_regs(input, regs);
 

-- Pete
-
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] MMC host class

[Pierre Ossman]

Russell King wrote:

>On Fri, Jul 15, 2005 at 10:21:43PM +0200, Pierre Ossman wrote:
>  
>
>>Russell King wrote:
>>
>>
>>>Also note that since we have a class_dev, the mmc_host 'dev' field can
>>>be removed.  However, we'll probably have to update the host drivers
>>>to do this, so it should be a separate patch.
>>>  
>>>
>>I believe there's a bit of abstraction to be gained from not poking
>>around inside the class_dev struct in too many places. It's not like
>>we're wasting any large amounts of memory.
>>
>>
>
>I still don't like the needless duplication.  How about doing it this
>way (see the attached patch.)
>  
>

The mmc_hostname macro seems like a good solution. It'll keep the
abstraction even if stuff needs to be moved around.

I see a problem with waiting until mmc_add_host() until initialising the
kobject though. If a driver calls mmc_alloc_host() and then
mmc_free_host(), perhaps because of some error, then the structure won't
be freed since we rely on release getting called. That's why I tried to
get the kobject stuff set up with the allocation.

Perhaps it is possible to test if a kobject is initialised and if not
free the structure directly?

Rgds
Pierre

-
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.13-rc3 from today: No Toshiba ACPI module load?

[Dumitru Ciobarcianu]

În data de Sî, 16-07-2005 la 22:56 -0400, Horst von Brand a scris:
> I'm getting:
> # modprobe toshiba_acpi
> FATAL: Error inserting toshiba_acpi 
> (/lib/modules/2.6.13-rc3/kernel/drivers/acpi/toshiba_acpi.ko): No such device
> 
> This is definitely a Toshiba M30 notebook with this.
> Anything else that might be useful?

Does your toshiba use an Phoenix BIOS ?
If yes, the toshiba_acpi module does not apply.

-- 
Cioby


-
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/

Linux 2.6.11.5 on R3912 problems

[Mark Underwood]

Hi,

I have now been trying to get Linux 2.6.11.5 (built
with gcc 3.3.3 and binutils 2.15.91.0.2) up and
running on my Helio PDA, a MIPS R3912 based ASSP (the
emulator to be exact) and have been stuck at the last
step for a while now :-(. 

The kernel runs up fine, the problem starts when init
is started. Bellow is my kernel log up to freeing
init.

Uncompressing
Linux
done, booting the kernel.
done decompressing kernel.
e_entry: 8016b000, e_ehsize: 52, e_phentsize 32,
e_phnum 2,
e_shentsize 40, e_shnum 25
copying 0x10c320 bytes from file offset 0x80 to
address 0x8004
zeroing from 8014c320 to to 8014c320, 0x0 bytes
copying 0x36084 bytes from file offset 0x10e000 to
address 0x8014e000
zeroing from 80184084 to to 80198b58, 0x14ad4 bytes
done loading kernel, about to jump in!
mips_machgroup 0x0017, mips_machtype 0x
arcs_cmdline: root=1f01 console=ttyS0,115200n8
Linux version 2.6.11.5 ([EMAIL PROTECTED]) (gcc version
3.3.3) #297 Mon Jul 18 20:19
:39 UTC 2005
V nasty hack. The Emulator doesn't report which subset
of the TX39 family it bel
ongs to :,-(. I hope the hardware does!
Forcing cpu type to CPU_TX3912
CPU revision is: 2200
Determined physical RAM map:
 memory: 00267000 @ 00199000 (usable)
 memory: 0040 @ 0200 (usable)
 memory: 0020 @ 9fc0 (ROM data)
Built 1 zonelists
Kernel command line: root=1f01 console=ttyS0,115200n8
Primary instruction cache 1kB, linesize 16 bytes
Primary data cache 1kB, linesize 4 bytes
Synthesized TLB handler (17 instructions).
Synthesized TLB load handler fastpath (37
instructions).
Synthesized TLB store handler fastpath (37
instructions).
Synthesized TLB modify handler fastpath (29
instructions).
PID hash table entries: 256 (order: 8, 4096 bytes)
r39xx_set_termios
Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
Memory: 6168k/6556k available (981k kernel code, 348k
reserved, 212k data, 104k
init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096
bytes)
Checking for 'wait' instruction...  unavailable.
cpu_wait = 0x0
Linux NoNET1.0 for Linux 2.6
schedule = 0x801327f8. ret = 0
Can't analyze prologue code at 80133ea0
schedule_timeout = 0x80133ea0. ret = -1
sleep_on = 0x8013395c. ret = 0
sleep_on_timeout = 0x80133a54. ret = 0
wait_for_completion = 0x80133148. ret = 0
Serial: r39xx internal UART driver $
r39xx_config_port
r39xx_request_port
ttyS0 at MMIO 0x0r39xx_type
 (irq = 74) is a R39XX
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 blocksize
loop: loaded (max 8 devices)
Helio Boot ROM: 0x0020 at 0x9fc0
helio_mtd_map.virt 0x9fc0
Helio Boot ROM: probing for ROM
Creating 2 MTD partitions on "Helio Boot ROM":
0x-0x00097eec : "Bootloader + Kernel"
mtd: Giving out device 0 to Bootloader + Kernel
0x00097eec-0x0013deec : "cramfs Filesystem"
mtd: Giving out device 1 to cramfs Filesystem
block2mtd: version $Revision: 1.23 $
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 104k freed

I have had to write a UART driver so I thought the
problem might be with that so I put lots of debug in
tty layer, serial_core and my driver to see what was
going on. After doing this and changing the interrupt
handler (int-handler.S) I saw the echo that I had put
in my inittab.
So I started to remove debug and found it stopped
working. The strange thing is that it stops before it
gets as far as sending the echo from inittab.
If I don’t have enough debug the kernel stops just
before printing out:

Algorithmics/MIPS FPU Emulator v1.5

When I connect to the emulator with GDB and look at
the registers I find the CPU is still running and is
in cpu_idle.
I wondered if it might be a timer/task scheduler
related problem but as it gets passed the bogomips
calculation the timer must be working.

Any help would be great as I have been stuck here for
a while.

Many Thanks,

Mark




___ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
-
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/

NAPI (aka RX Polling) for natsemi?

[Daniel Higgins]

hi all,
is there such a thing anywhere as a working patch to enable NAPI in the
natsemi driver? or is someone working on one?

so far i have found two non-working patches, which i tried to get to
work without success. one locks up the kernel, the other says "interrupt
while polling". any help with these would be appreciated.
the DP83815 (natsemi) are used a lot on embedded routers (soekris, wrap,
routerboard) and since they all use a geode processor which isn't all
that powerful, they get stuck in a livelock at around 50-60 mbits and
reboot shortly after due to the watchdog

here's the patches i found if that can help anyone:
http://gnumonks.org/ftp/pub/patches/natsemi-napi.patchlocks up the
kernel once it receives some packet (guessing it's stuck in polling mode.. )
http://www.spine-group.org/sources/natsemi.diffhas "interrupts while
polling" messages and the throughput drops off to zero

cc: me because i'm not subscribed

thanks for any help and pointers



-
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/

[shorty: Re: 2.6.12 debian powerpc kernels and ppc64 ...]

[Wolfgang Pfeiffer]

The first try to send the message below didn't work. Hoping it does
now ... :)

Regards
Wolfgang

- Forwarded message from Wolfgang Pfeiifer -

To: Sven Luther <[EMAIL PROTECTED]>
Cc: debian-powerpc@lists.debian.org, debian-kernel@lists.debian.org,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.12 debian powerpc kernels and ppc64 ...
Date: Mon, 18 Jul 2005 22:17:37 +0200
User-Agent: Mutt/1.5.9i
X-URL: http://www.wolfgangpfeiffer.com

On Mon, Jul 18, 2005 at 07:23:05AM +0200, Sven Luther wrote:
> On Sun, Jul 17, 2005 at 07:52:30PM +0200, Wolfgang Pfeiffer wrote:
> > Hi Sven
> > 
> > On Fri, Jul 15, 2005 at 11:04:17PM +0200, Sven Luther wrote:
> > > Hello,
> > > 
> > > I would like testers who want to test new powerpc kernels on ppc64 
> > > machines :
> > > 
> > > These i have uploaded here :
> > > 
> > >   
> > > http://people.debian.org/~luther/ppc64/kernel-image-2.6.12-sven_1_powerpc.deb
> > 
> > At least the latter one works here. Or at least it boots here without any 
> > probs,
> > as it seems .. :
> > 
> > $ uname -a
> > Linux debby 2.6.12-sven #1 Fri Jul 15 13:44:26 UTC 2005 ppc GNU/Linux
> > 
> > $ cat /proc/cpuinfo 
> > processor   : 0
> > cpu : 7455, altivec supported
> > clock   : 867MHz
> > revision: 0.2 (pvr 8001 0302)
> > bogomips: 865.18
> > machine : PowerBook3,5
> > motherboard : PowerBook3,5 MacRISC2 MacRISC Power Macintosh
> > detected as : 80 (PowerBook Titanium IV)
> > pmac flags  : 001b
> > L2 cache: 256K unified
> > memory  : 768MB
> > pmac-generation : NewWorld
> 
> As was expectet, the 64bit is the one i am not sure about.
> 
> > But how come this kernel still does not have the necessary patches
> > applied to run kismet: 
> 
> Please provide a bug report with this info, 

No. Please see:
http://lkml.org/lkml/2004/8/27/303

As you can see I sent them a bug report once. It won't happen again in
the foreseeable future.

And as you also can see from the thread info on the left-hand bar of
that page nobody seemed to be interested in the problem. IIRC I could
not compile for weeks or perhaps even months a new 2.4 kernel version
because of the mentioned errors.

> i will apply as soon as i am back
> in 2 weeks, if someone from the kernel team doesn't beat me to it.

The site for the patch I used, IIRC:


wget http://www.kismetwireless.net/code/orinoco-2.6.12-rfmon-dragorn-1.diff

The md5sum for the latter that I have here is 
41fb7cec09f4de93cd2432eb1aceba92

So if yours will be different you can let me know.

And I applied the patch to 2.6.12. Or better: I probably patched a
2.6.11 (tarball) source with patch-2.6.12.bz2, and then applied the
above orinoco patch. (Uncertainty because it's already a few weeks ago
I compiled this kernel ... ) 

And just in case it might help someone else:
The following snippet might serve as an example of how to compile this
more or less wifi ready patched source [Please check for yourself in
case I made any mistakes ... :) ... ]:


tar xzvf linux-2.6.11.tar.gz
cd linux-2.6.11/
bzip2 -cd  /path/to/patch-2.6.12.bz2 | patch -p1

[then applying the orinoco patch from above]

cp /boot/someconfig .
make oldconfig
fakeroot make-kpkg clean

time MAKEFLAGS="CC=gcc-4.0"  fakeroot make-kpkg --append-to-version=-somename 
--revision +anothername kernel_image

or

 time MAKEFLAGS="CC=gcc-4.0"  fakeroot make-kpkg 
--append-to-version=+orinoco-patched --revision +050703 kernel_image


HTH

Thanks for responding, Sven ... and yes: for your work, too :)

And sorry for refusing to play nice if things run ugly ..

Best Regards
Wolfgang

-- 
Wolfgang Pfeiffer
http://profiles.yahoo.com/wolfgangpfeiffer

- End forwarded message -

-- 
Wolfgang Pfeiffer
http://profiles.yahoo.com/wolfgangpfeiffer
-
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.6.13-rc1 05/10] IOCHK interface for I/O error handling/detecting

[Grant Grundler]

On Wed, Jul 06, 2005 at 02:11:42PM +0900, Hidetoshi Seto wrote:
> [This is 5 of 10 patches, "iochk-05-check_bridge.patch"]
...
>   It means that A or B hits a bus error, but there is no data
>   which one actually hits the error. So, C should notify the
>   error to both of A and B, and clear the H's status to start
>   its own I/Os.
> 
>   If there are only two devices, it become more simple. It is
>   clear if one find a bridge error while another is check-in,
>   the error is nothing except for another's.

Sorry, I don't understand this last paragraph.
I don't see how it's more simple with two devices (vs three) if
we don't exactly know which device caused the error. I thought
one still needed to reset/restart both devices. Is that correct?

The devices operate asyncronously from the drivers.
Only the driver can tell us for sure if IO was in flight for a
particular device and decide that a device could NOT have generated
an error.


Otherwise, so far, the patches look fine to me.

thanks,
grant
-
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: [Ext2-devel] [RFC] [PATCH 2/4]delayed allocation for ext3

[Mingming Cao]

On Sun, 2005-07-17 at 19:47 -0600, Andreas Dilger wrote:
> On Jul 17, 2005  10:40 -0700, Mingming Cao wrote:
> > @@ -373,6 +373,7 @@ struct ext3_inode {
> >  #define EXT3_MOUNT_BARRIER 0x2 /* Use block barriers */
> >  #define EXT3_MOUNT_NOBH0x4 /* No bufferheads */
> >  #define EXT3_MOUNT_QUOTA   0x8 /* Some quota option set */
> > + #define EXT3_MOUNT_DELAYED_ALLOC  0xC /* Delayed Allocation */
> 
> This doesn't make sense.  DELAYED_ALLOC == QUOTA | NOBH?
> 


Ah...:-)  Badari used 0x8 for DELAYED_ALLOC in the previous patch
(2.6.11 based).When moving those patches forward to 2.6.13-rc3, we found
the conflict with QUOTA, and obviously picked up a wrong value.

> > + {Opt_delayed_alloc, "delalloc"},
> 
> Is this a replacement for Alex's delalloc code?  We also use delalloc for
> that code and if they are not interchangeable it will cause confusion
> about which one is in use.
> 

Okey, will think a new name for this feature to avoid confusion.  Alex's
delalloc is bond to extent tree structure so it's hard to be adopted
directly to the current ext3 layout, so, I'd say this work done by
Badari(inspired by Alex's work) is a different implementation.

> > + if (test_opt(sb, DELAYED_ALLOC)) {
> > + if (!(test_opt(sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)) 
> > {
> > + printk(KERN_WARNING "EXT3-fs: Ignoring delall option 
> > - "
> > + "its supported only with writeback mode\n");
> 
> Should be "ignoring delalloc option".
>  
Fixed. 


Thanks for looking at this.

Mingming


-
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/

[swsusp] swsusp process freezing: remove smp races

[Pavel Machek]

From: Christoph Lameter <[EMAIL PROTECTED]>

The current suspend code modifies thread->flags from outside the
context of the thread. This creates a SMP race.

This patch fixes that by introducing a TIF_FREEZE flag in thread_info.

(This is not the end of the races in the suspend code since TIF_FREEZE
is cleared when setting PF_FROZEN creating a window for
freeze_processes(). OTOH, this patch actually works :-)

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

---
commit b3ace94a1a465a2084bed642021aa8c8ddd912d1
tree 479de81d32de97f456f5d2929597f4047e1aab6f
parent e83468048173e800bfc4dc09c2d609f9983cd29d
author <[EMAIL PROTECTED](none)> Mon, 18 Jul 2005 22:20:46 +0200
committer <[EMAIL PROTECTED](none)> Mon, 18 Jul 2005 22:20:46 +0200

 include/asm-alpha/thread_info.h |1 +
 include/asm-arm/thread_info.h   |1 +
 include/asm-arm26/thread_info.h |1 +
 include/asm-cris/thread_info.h  |1 +
 include/asm-frv/thread_info.h   |1 +
 include/asm-h8300/thread_info.h |1 +
 include/asm-i386/thread_info.h  |1 +
 include/asm-ia64/thread_info.h  |1 +
 include/asm-m32r/thread_info.h  |1 +
 include/asm-m68k/thread_info.h  |1 +
 include/asm-m68knommu/thread_info.h |1 +
 include/asm-mips/thread_info.h  |1 +
 include/asm-parisc/thread_info.h|1 +
 include/asm-ppc/thread_info.h   |1 +
 include/asm-ppc64/thread_info.h |1 +
 include/asm-s390/thread_info.h  |1 +
 include/asm-sh/thread_info.h|1 +
 include/asm-sh64/thread_info.h  |1 +
 include/asm-sparc/thread_info.h |1 +
 include/asm-sparc64/thread_info.h   |1 +
 include/asm-um/thread_info.h|1 +
 include/asm-v850/thread_info.h  |1 +
 include/asm-x86_64/thread_info.h|1 +
 include/asm-xtensa/thread_info.h|1 +
 include/linux/sched.h   |9 -
 25 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/include/asm-alpha/thread_info.h b/include/asm-alpha/thread_info.h
--- a/include/asm-alpha/thread_info.h
+++ b/include/asm-alpha/thread_info.h
@@ -78,6 +78,7 @@ register struct thread_info *__current_t
 #define TIF_UAC_NOFIX  7
 #define TIF_UAC_SIGBUS 8
 #define TIF_MEMDIE 9
+#define TIF_FREEZE 10
 
 #define _TIF_SYSCALL_TRACE (1flags & PF_FREEZE;
+   return test_ti_thread_flag(p->thread_info, TIF_FREEZE);
 }
 
 /*
  * Request that a process be frozen
- * FIXME: SMP problem. We may not modify other process' flags!
  */
 static inline void freeze(struct task_struct *p)
 {
-   p->flags |= PF_FREEZE;
+   set_ti_thread_flag(p->thread_info, TIF_FREEZE);
 }
 
 /*
@@ -1317,7 +1315,8 @@ static inline int thaw_process(struct ta
  */
 static inline void frozen_process(struct task_struct *p)
 {
-   p->flags = (p->flags & ~PF_FREEZE) | PF_FROZEN;
+   p->flags |= PF_FROZEN;
+   clear_ti_thread_flag(p->thread_info, TIF_FREEZE);
 }
 
 extern void refrigerator(void);

-- 
teflon -- maybe it is a trademark, but it should not be.
-
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.13rc3: crypto horribly broken on all 64bit archs

[David S. Miller]

From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 18 Jul 2005 06:45:54 +1000

> On Sun, Jul 17, 2005 at 02:20:21PM +0200, Andreas Steinmetz wrote:
> > 
> > The compiler first does ~((a)-1)) and then expands the unsigned int to
> > unsigned long for the & operation. So we end up with only the lower 32
> > bits of the address. Who did smoke what to do this? Patch attached.
> 
> Thanks for the patch Andreas.  A similar patch will be in the
> mainline kernel as soon as everybody is back home from Canada.

Yes, the fix is in my tree and will make it's way upstream
as soon as possible.
-
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: [GIT PATCH] Remove devfs from 2.6.12-git

[Jan Engelhardt]

>Greg KH writes:
>> I do care about this, please don't think that.  But here's my reasoning
>> for why it needs to go:
>[...]
>>  - original developer of devfs has publicly stated udev is a
>>replacement.
>
>Well, that's news to me!

What is more news to me: 
( http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ )
Q: Why was devfs marked OBSOLETE if udev is not finished yet?
A: To quote Al Viro (Linux VFS kernel maintainer):
==> - the devfs maintainer/author disappeared and stoped maintaining the code

So, if you allow the question, where [t.h.] have you been in the meantime?

>>  - clutter and mess
>In the eye of the beholder.
It's kernel code - I think the point is valid.

>>  - code is broken and unfixable
>No proof. Never say never...

*thumbs up* You could just become the maintainer of ndevfs. :)


Something's wondering me, though:
FreeBSD "just" (5.0) introduced devfs, so either they are behind The Facts 
(see udev FAQ), or devfs (anylinux/anybsd) is not so bad after all.



Jan Engelhardt
-- 
-
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 8/8] pci and yenta: pcibios_bus_to_resource

[Grant Grundler]

On Tue, Jul 12, 2005 at 12:21:38AM +0200, Dominik Brodowski wrote:
> In yenta_socket, we default to using the resource setting of the CardBus
> bridge. However, this is a PCI-bus-centric view of resources and thus
> needs to be converted to generic resources first. Therefore, add a call
> to pcibios_bus_to_resource() call in between. This function is a mere
> wrapper on x86 and friends, however on some others it already exists, is
> added in this patch (alpha, arm, ppc, ppc64) or still needs to be 
> provided (parisc -- where is its pcibios_resource_to_bus() ?).

in arch/parisc/kernel/pci.c?
At least, it seems to be present in the 2.6.13-rc1 tree
on cvs.parisc-linux.org tree.

Arnaldo De Carmelo had add-on pci-pcmcia cards working in his
a500 (64-bit w/IOMMU PA-RISC) last year.  ISTR a few other people have
similar cards working for on B180 workstation (32-bit w/o IOMMU PARISC).

grant
-
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: Fix missing refrigerator invocation in jffs2.

[Jörn Engel]

On Mon, 18 July 2005 14:14:53 +1000, Nigel Cunningham wrote:
> 
> Here's a patch to fix a missing refrigerator call in jffs2.
   ^
You should shorten the description by one letter, roughly. ;)

> 
> Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>
> 
>  intrep.c |3 +++
>  1 files changed, 3 insertions(+)
> diff -ruNp 235-jffs-intrep.patch-old/fs/jffs/intrep.c 
> 235-jffs-intrep.patch-new/fs/jffs/intrep.c
> --- 235-jffs-intrep.patch-old/fs/jffs/intrep.c2005-07-18 
> 06:36:59.0 +1000
> +++ 235-jffs-intrep.patch-new/fs/jffs/intrep.c2005-07-18 
> 14:02:27.0 +1000
> @@ -3397,6 +3397,9 @@ jffs_garbage_collect_thread(void *ptr)
>   siginfo_t info;
>   unsigned long signr = 0;
>  
> + if (try_to_freeze())
> + continue;
> +
>   spin_lock_irq(>sighand->siglock);
>   signr = dequeue_signal(current, >blocked, 
> );
>   spin_unlock_irq(>sighand->siglock);
> 
> -- 
> Evolution.
> Enumerate the requirements.
> Consider the interdependencies.
> Calculate the probabilities.
> Be amazed that people believe it happened. 
> 
> -
> 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/

Jörn

-- 
A quarrel is quickly settled when deserted by one party; there is
no battle unless there be two.
-- Seneca
-
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: shared subtrees implementation writeup

[Ram Pai]

On Mon, 2005-07-18 at 04:06, Miklos Szeredi wrote:
> Thanks for the writeup, it helps to understand things a bit better.
> However I still don't understand a few things:
> 
> 
> > Section 1. mount:
> > 
> > to begin with we have a the following mount tree 
> > 
> >  root
> >   / /  \  \ \
> >  /  t1  t2 \  \ 
> >t0   t3 \
> > t4
> > 
> > note: 
> > t0, t1, t2, t3, t4 all contain mounts.
> > t1 t2 t3 are the slave of t0. 
> > t4 is the slave of t2.
> > t4 and t3 is marked as shared.
> > 
> > The corresponding propagation tree will be:
> > 
> > p0
> >   /   \
> >  p1   p2
> >  / 
> >  p3
> > 
> > 
> > ***
> >   p0 contains the mount t0, and contains the slave mount t1
> >   p1 contains the mount t2
> >   p3 contains the mount t4
> >   p2 contains the mount t3
> > 
> >   NOTE: you may need to look at this multiple time as you try to
> > understand the various scenarios.
> > ***
> 
> Why you have p2 and p3?  They contain a single mount only, which could
> directly be slaves to p0 and p1 respectively.  Does it have something
> to do with being shared?

Yes. If the mounts were just slave than they could be a slave member of
their corresponding master pnode, i.e p0 and p1 respectively. But 
in my example above they are also shared. And a shared mount could be
bind mounted with propagation set in either direction. Hence they
deserve a separate pnode.  If it was just a slave mount then binding to
it would not set any propagation and hence there need not be a separate
pnodes to track the propagation.

Just for clarification:
1. a slave mount is represented as a slave member of a pnode.
2. a shared mount is represented as a member of a  pnode.
3. a slave as well as a shared mount is represented a member of
separate pnode, which in itself is a slave pnode.
4. a private mount is not part of any pnode.
5. a unclone mount is also not part of any pnode.


> 
> BTW, is there a reason not to include the pnode info in 'struct
> vfsmount'?  That would simplify a lot of allocation error cases.
> 
> > The key point to be noted in the above set of operations is:
> > each pnode does three different operations corresponding to each stage.
> > 
> > A. when the pnode is encountered the first time, it has to create
> > a new pnode for its child mounts.
> > B. when the pnode is encountered again after it has traversed down
> >each slave pnode, it has to associate the slave pnode's newly created
> >pnode with the pnode's newly created pnode.
> > C. when the pnode is encountered finally after having traversed through
> > all its slave pnodes, it has to create new child mounts
> > for each of its member mounts.
> 
> Now why is this needed?  Couldn't each of these be done in a single step?
> 
> I still can't see the reason for having these things done at different
> stages of the traversal.

Yes. This can be done in a single step. And in fact in my latest patches
that I sent yesterday I did exactly that. It works. All that messy
PNODE_UP,PNODE_DOWN,PNODE_MID is all gone. Code has become
much simpler.

The reason this was there earlier was that I was thinking we may need
all these phases for some operations like umount, make_mounted.. 
But as I understand the operations better I am convinced that it is not
required, and you reconfirm that point :)

Thanks,
RP
> 
> Thanks,
> Miklos

-
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: [GIT PATCH] Remove devfs from 2.6.12-git

[Richard Gooch]

Greg KH writes:
> I do care about this, please don't think that.  But here's my reasoning
> for why it needs to go:
[...]
>   - original developer of devfs has publicly stated udev is a
> replacement.

Well, that's news to me!

>   - policy in the kernel.

Like sysfs :-)

>   - clutter and mess

In the eye of the beholder.

>   - code is broken and unfixable

No proof. Never say never...

Regards,

Richard
-
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.12.3 ompilation errors with linux1394.org rev.1315

[art]

2.6.12.3 ompilation errors with linux1394.org rev.1315

[]$ make && make modules
..
LD  drivers/ieee1394/built-in.o
  CC [M]  drivers/ieee1394/ieee1394_core.o
drivers/ieee1394/ieee1394_core.c: In function ‘hpsbpkt_thread’:
drivers/ieee1394/ieee1394_core.c:1035: error: too few arguments to function 
‘try_to_freeze’
drivers/ieee1394/ieee1394_core.c: In function ‘ieee1394_init’:
drivers/ieee1394/ieee1394_core.c:1113: warning: implicit declaration of 
function ‘class_create’
drivers/ieee1394/ieee1394_core.c:1113: warning: assignment makes pointer from 
integer without a cast
drivers/ieee1394/ieee1394_core.c:1151: warning: implicit declaration of 
function ‘class_destroy’
make[2]: *** [drivers/ieee1394/ieee1394_core.o] Error 1
make[1]: *** [drivers/ieee1394] Error 2
make: *** [drivers] Error 2


xboom

-
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: how to be a kernel developer ?

[Andrew Ruder]

Alejandro Bonilla wrote:

This exact question is made at least every 15 days. Did you google? You will
need to make that your Home Page.


And after that, make your first google search kernelnewbies.

- Andrew Ruder
-
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.12.3/2.6.13-rc3 BUG REPORT - x86_64 with hyperthreading

[Maxim Kozover]

Hi!
I tried 2.6.12.3/2.6.13-rc3 compiled for x86_64 on Supermicro dual Xeon
with hyperthreading enabled and the kernel gets stuck when trying to
initialize the second CPU.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU0: Thermal monitoring enabled (TM1)
Using local APIC timer interrupts.
Detected 12.501 MHz APIC timer.
Booting processor 1/6 rip 6000 rsp 81007ff35f58
Initializing CPU#1
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 3
CPU1: Thermal monitoring enabled (TM1)
  Intel(R) Xeon(TM) CPU 2.80GHz stepping 01
CPU 1: Syncing TSC to CPU 0.
Booting processor 2/1 rip 6000 rsp 8100032dff58
Initializing CPU#2

Booting with hyperthreading disabled is OK.
Booting with hyperthreading enabled and maxcpus=1 is also OK.

Here are board/bios details:
Supermicro X6DH8-XG2/X6DHE-XG2 BIOS Rev 1.2a

CPU = 4 - Intel(R) Xeon(TM) CPU 2.80GHz
DRAM Type : DDR2-400
Hyper Threading Technology Enabled

Please advise.

Thanks,

Maxim Kozover.

-
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: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble

[Alan Stern]

On Sun, 17 Jul 2005, Michel Bouissou wrote:

> I'm afraid I won't have time for this today. It's already more than 11 PM 
> here 
> and I'm leaving early tomorrow for travel...

I will be travelling this week also.  That's okay, there's no hurry.

> But AFAIR, when I performed previous tests, I had tried about every USB 
> socket 
> on my computer (I have 6 of them...) to the same result.

But you didn't try these exact tests.

> Humm. I'm not sure about what you call a "full speed" device, for when I plug 
> my USB scanner, my kernel reports it as a "full speed" USB device, and says 
> it's managed by uhci (not ehci):
> 
> Jul 17 22:46:42 totor kernel: usb 3-2: new full speed USB device using 
> uhci_hcd and address 3

That's what I mean by a "full speed device".

> I just tried an USB flashdisk that "used to work good with 2.4" and that I 
> hadn't tried yet in 2.6. It's identified as "high speed" and ehci would like 
> to manage it, but it seems I'm out of luck in some other aspect:
> 
> totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 25
> totor kernel: usb 4-4: device not accepting address 25, error -71
> totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 35
> totor kernel: usb 4-4: device not accepting address 35, error -71
> totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 36
> totor kernel: usb 4-4: device not accepting address 36, error -71
> totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 38
> totor kernel: usb 4-4: device not accepting address 38, error -71
> totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 48
> totor kernel: usb 4-4: device not accepting address 48, error -71
> 
> ...ad nauseam until I unplug the key...

This could be the result of inadequate cabling inside the computer case
from the front panel socket to the motherboard.  Lots of other people have
seen that sort of thing.

> Shhh... 
> 
> Doesn't like the front panel socket ? Let me try another USB socket... Just 
> close to my mouse...
> 
> totor kernel: usb 4-2: new high speed USB device using ehci_hcd and address 16
> totor kernel: SCSI subsystem initialized
> totor kernel: Initializing USB Mass Storage driver...
> totor kernel: scsi0 : SCSI emulation for USB Mass Storage devices
> totor kernel: usbcore: registered new driver usb-storage
> totor kernel: USB Mass Storage support registered.
> 
> Looks better, isn't it ?
> 
> Now, I checked that I can mount it and see its contents. That's OK.
> 
> I'm currently running with IO-APIC disabled, so my interrupts shows as:

For the tests I described earlier, you will want to boot with IO-APIC 
enabled.  Otherwise there's nothing to test...


> I know that what I'm going to write will look crazy ;-) because it doesn't 
> seem to make any sense, but I've noticed a pattern that tends to emerge from 
> the different tests I've made with IO-APIC enabled and different 2.6.12 
> kernels (patches, boot options, etc...) :
> 
> 1/ When I'm testing a new kernel for the first time, I usually call it 
> manually by typing the different relevant option manually from my grub 
> (bootloader) commandline, and most of the times, it works without "losing IRQ 
> 21".
> That's why I had thought, with your first suggestion of "usb-handoff" option, 
> that my problem was solved.
> 
> Once I believe it works and want to test it again, I then put this as the 
> default entry in my bootloader, then I reboot without touching anything (I 
> let the bootloader select its default entry), and, usually, it then fails.
> 
> So I would say that a patterns looks emerging : When I have typed things on 
> the keyboard at the bootloader stage, then loaded Linux, it may work. On the 
> contrary, when I let the machine boot by itself without having touched 
> anything, then I usually get these IRQ 21 losses.
> 
> Yes, I know this look completely silly ;-) but I mentioned it to be as 
> complete as possible about what I noticed, and that may or may not be 
> relevant...

I would be very surprised if this turned out to mean anything.  But it 
doesn't hurt to try more tests, doing it both ways, and see what happens.


> By the way, the front socket that dislikes the USB 2.0 flashdisk (ehci) feels
> perfectly happy if I plug and USB 1.1 flashdisk (uhci)... Feels good also if 
> I plug my Digital Camera there... And I've plugged it there thousands of
> times.

That's to be expected from bad cabling.  Full-speed transmissions are much 
more tolerant of interference and noise than high-speed transmissions.

> Some posts I googled about this kind of errors tend to indicate this would be
> an IRQ mess ;-))

Sometimes it is.  And many of those posts are just guesses.  In your case
you know that the IRQs work correctly when you don't enable IO-APIC.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo 

Re: ANNOUNCE: Driver for Rocky 4782E WDT and pls help

[Alan Cox]

On Llu, 2005-07-18 at 15:08 -0700, Gyorgy Horvath wrote:
>- Half of the RAM were stolen from Linux.
>  (mem= kernel parameter)
>  This range was requeset_mem_region-ed, then
>  ioremap-ped for bus mastering DMA transfer.
>  Actually 30 M is used.

Did you make sure none of that is ACPI owned in the E820 map and that if
you set any cache properties they match and are consistent with any
Linux pagetable uses ?

>- Issuing a simple ls -la / surelly causes instant death.

Is this also true with ide=nodma ?

>hardware bug. None. I feel it.  Although I noticed that
>someone (not me) takes control of the PC - time to time -
>for cca. 400..500 usec so that no DMA can occur.

Probably SMM firmware. Make sure you have USB driver loaded. Consider
turning ACPI and APM off

>Moreover, I have applied a breakpoint to sscanf in the
>shared.o. Disassembling the the code causes sudden death
>at a given point. The code portions were not executed, just
>disassembled. What the hell is that?

Smells like broken hardware.

-
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: Merging relayfs?

[Tom Zanussi]

Roman Zippel writes:
 > Hi,
 > 
 > On Mon, 18 Jul 2005, Karim Yaghmour wrote:
 > 
 > > I guess I just don't get the point here. Why cut something away if many
 > > users will need it. If it's that popular that you're ready to provide a
 > > library function to do it, then why not just leave it to boot? One of the
 > > goals of relayfs is to avoid code duplication with regards to buffering
 > > in general.
 > 
 > The road to bloatness is paved with lots of little features.
 > There aren't that many users anyway (none of the examples use that 
 > feature). I'd prefer to concentrate on a simple and correct relayfs layer 
 > and we can still think about other features as more users appear.
 > Starting a design by implementing every little feature which _might_ be 
 > needed is a really bad idea.
 > 

OK, if we got rid of the padding counts and commit counts and let the
client manage those, we can simplify the buffer switch slow path and
make the API simpler in the process.  Here's a first proposal for
doing that - I won't know until I actually do it what snags I may run
into, but if this looks like the right direction to go, I'll go ahead
with it...

- get rid of the padding counts - the client can manage those if it
wants to, but in any case pass the padding for the previous sub-buffer
in to the subbuf_start callback.

- get rid of the commit counts - the client can manage those.  Also,
get rid of the related API functions that deal with those
i.e. relay_commit() and the deliver() callback.

- change the buffer_start() callback to something like the following
(the body shows an example of what would typically be done by a
client):

/*
 * subbuf_start() callback.
 *
 * Return 1 to allow logging to continue, 0 to stop.
 */
static int subbuf_start_default_callback (struct rchan_buf *buf,
  void *subbuf,
  void *prev_subbuf,
  int prev_padding)
{
*((int *)prev_subbuf) = prev_padding;

if (relay_buf_full(buf))
return 0;

relay_reserve(subbuf, sizeof (int));

return 1;
}

- add a relay_reserve() function for the client to use to reserve
space at the beginning of the sub-buffer (it can use this reserved
space to save the padding among other things).  This would be used by
the client in the subbuf_start callback, rather than returning it via
an outparam or struct.

- remove the buf_full() callback - the client can determine this in
the subbuf_start() callback.

Also, as far as the netlink/ioctl/proc file communication, I'll have
to think more about it, but will play around with something when I
update the example code.

Let me know if this sounds ok, or if you have better suggestions.

Thanks,

Tom




-
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] I-pipe 2.6.12-v0.9-02

[Gene Heskett]

On Monday 18 July 2005 09:41, Philippe Gerum wrote:
>The interrupt pipeline patch v0.9-02 has been released, fixing a
> latency spot and a bug in the deferred printk() mechanism.
>
>A split version of the patch for x86, ppc32 and ia64 is available
> here: http://download.gna.org/adeos/patches/v2.6/ipipe/split/
>
>Patch sequence to build a Linux 2.6.12 tree with I-pipe support:
>
>http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2
>http://download.gna.org/adeos/patches/v2.6/ipipe/ipipe-2.6.12-v0.9-0
>2.patch

Will this then work with emc?  emc, when run, loads the adeos stuff, 
then unloads it when its stopped.  emc being the linux cnc machine 
controller.

If it will, I'd like to play with it on a bdi-4.20 install.

Or is this a seperate patch?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
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.12-rc2 and as-iosched

[Jens Axboe]

On Mon, Jul 18 2005, Jens Axboe wrote:
> On Mon, Jul 18 2005, Kenneth Parrish wrote:
> > Randy> Need more info.
> > 
> > Greetings.  :)
> > CONFIG_HZ_ changes the block device elevator time-out values -- didn't see.
> 
> I cannot reproduce here with cfq and HZ == 250, the jiffies <-> msec
> conversions are working fine. Please provide a proper bug report, did
> you change the values and not getting the expected back, or what is
> going wrong??

ok, AS is definitely broken, it does an internal HZ <-> msec conversion
in the store/show functions as well. This should fix it.

--- /opt/kernel/linux-2.6.13-rc3/drivers/block/as-iosched.c 2005-07-13 
06:46:46.0 +0200
+++ linux-2.6.13-rc3/drivers/block/as-iosched.c 2005-07-18 15:46:23.0 
+0200
@@ -1935,23 +1935,15 @@
 static ssize_t
 as_var_show(unsigned int var, char *page)
 {
-   var = (var * 1000) / HZ;
return sprintf(page, "%d\n", var);
 }
 
 static ssize_t
 as_var_store(unsigned long *var, const char *page, size_t count)
 {
-   unsigned long tmp;
char *p = (char *) page;
 
-   tmp = simple_strtoul(p, , 10);
-   if (tmp != 0) {
-   tmp = (tmp * HZ) / 1000;
-   if (tmp == 0)
-   tmp = 1;
-   }
-   *var = tmp;
+   *var = simple_strtoul(p, , 10);
return count;
 }
 

-- 
Jens Axboe

-
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: [Ext2-devel] [RFC] [PATCH 2/4]delayed allocation for ext3

[Andreas Dilger]

On Jul 17, 2005  10:40 -0700, Mingming Cao wrote:
> @@ -373,6 +373,7 @@ struct ext3_inode {
>  #define EXT3_MOUNT_BARRIER   0x2 /* Use block barriers */
>  #define EXT3_MOUNT_NOBH  0x4 /* No bufferheads */
>  #define EXT3_MOUNT_QUOTA 0x8 /* Some quota option set */
> + #define EXT3_MOUNT_DELAYED_ALLOC0xC /* Delayed Allocation */

This doesn't make sense.  DELAYED_ALLOC == QUOTA | NOBH?

> + {Opt_delayed_alloc, "delalloc"},

Is this a replacement for Alex's delalloc code?  We also use delalloc for
that code and if they are not interchangeable it will cause confusion
about which one is in use.

> + if (test_opt(sb, DELAYED_ALLOC)) {
> + if (!(test_opt(sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)) {
> + printk(KERN_WARNING "EXT3-fs: Ignoring delall option - "
> + "its supported only with writeback mode\n");

Should be "ignoring delalloc option".
 
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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: Realtime Preemption, 2.6.12, Beginners Guide?

[K.R. Foley]

Karsten Wiese wrote:

Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar:


* Karsten Wiese <[EMAIL PROTECTED]> wrote:


Have I corrected the other path of ioapic early initialization, which 
had lacked virtual-address setup before ioapic_data[ioapic] was to be 
filled in -51-28? Please test attached patch on top of -51-29 or 
later. Also on Systems that liked -51-28.


thanks - i've applied it to my tree and have released the -51-31 patch.  
It looks good on my testboxes.




Found another error:
the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init().
Please apply attached patch on top of -51-31.

Karsten



I have this successfully booted on both of my SMP boxes now.

--
   kr
-
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] no more need to check for NULL before calls to crypto_free_tfm

[Herbert Xu]

On Sun, Jul 17, 2005 at 12:32:27AM +0200, Jesper Juhl wrote:
> 
> --- linux-2.6.13-rc3-orig/drivers/block/cryptoloop.c  2005-06-17 
> 21:48:29.0 +0200
> +++ linux-2.6.13-rc3/drivers/block/cryptoloop.c   2005-07-16 
> 23:35:55.0 +0200
> @@ -227,14 +227,14 @@ cryptoloop_ioctl(struct loop_device *lo,
>  static int
>  cryptoloop_release(struct loop_device *lo)
>  {
> - struct crypto_tfm *tfm = (struct crypto_tfm *) lo->key_data;
> - if (tfm != NULL) {
> - crypto_free_tfm(tfm);
> - lo->key_data = NULL;
> - return 0;
> + struct crypto_tfm *tfm = lo->key_data;
> + if (!tfm) {
> + printk(KERN_ERR "cryptoloop_release(): tfm == NULL?\n");
> + return -EINVAL;
>   }
> - printk(KERN_ERR "cryptoloop_release(): tfm == NULL?\n");
> - return -EINVAL;
> + crypto_free_tfm(tfm);
> + lo->key_data = NULL;
> + return 0;
>  }

This change looks rather pointless.

The rest of the patch looks good.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Merging relayfs?

[Roman Zippel]

Hi,

On Mon, 18 Jul 2005, Karim Yaghmour wrote:

> I guess I just don't get the point here. Why cut something away if many
> users will need it. If it's that popular that you're ready to provide a
> library function to do it, then why not just leave it to boot? One of the
> goals of relayfs is to avoid code duplication with regards to buffering
> in general.

The road to bloatness is paved with lots of little features.
There aren't that many users anyway (none of the examples use that 
feature). I'd prefer to concentrate on a simple and correct relayfs layer 
and we can still think about other features as more users appear.
Starting a design by implementing every little feature which _might_ be 
needed is a really bad idea.

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/

Re: Merging relayfs?

[Roman Zippel]

Hi,

On Mon, 18 Jul 2005, Steven Rostedt wrote:

> > What exactly would be slowed down?
> > It would just move around some code and even avoid the overwrite mode 
> > check.
> 
> Yes, you're adding a jump to another function via a function pointer,
> that would kill the cache line of execution, to avoid a simple check, or
> some other way of handling it.

RTFS. (deliver_default_callback)

> Since I don't want to know the internals
> of relayfs,

You have to anyway, currently relayfs client need some knowledge about how 
buffers are managed.

> the overwrite mode could be implemented in a more officient way.

I wouldn't call the buffer switch routine efficient, yet.

> > > I don't see the problem with having an overwrite mode or not. Why
> > > can't relayfs know this?
> > 
> > The point is to design a simple and flexible relayfs layer, which means 
> > not every possible function has to be done in the relayfs layer, as long 
> > it's flexible enough to build additional functionality on top of it (for 
> > which it can again provide some library functions).
> 
> The overwrite mode isn't that complex.  You don't want to make something
> so flexible that it becomes more complex.  Assembly is more flexible
> than C but I wouldn't want to code a lot with it.  A library function
> for me is out of the question, since what I build on top of relayfs is
> mostly in the kernel.  The overwrite mode would then have to be
> implemented through another kernel activity.  I might as well keep my
> own ring buffers and forget about using relayfs, and all my points in
> which I argue for it being merged is mute.

I must admit I have no clue, what you're talking about here...
The keywords above are "_simple_ _and_ _flexible_".

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/

Avoiding BIGMEM support programatically.

[vamsi krishna]

Hello All,

I have a program working fine on a 2.6.xx-smp kernel, and the program
crashes on the same version kernel with bigmem i.e (2.6.xxx-bigmem).

I also found that for a same executable on bigmem kernel the virtual
address's of '&_start' and '&_etext', seem to vary in every new run.

Is there any way I can avoid the kernel's bigmem virtual address
mapping programatically? and still run the program on a bigmem kernel?

Really appreciate your help in this context.

Best Regards,
Vamsi Kundeti.
-
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] Interbench v0.20 - Interactivity benchmark

[Bill Davidsen]

[EMAIL PROTECTED] wrote:


Quoting Bill Davidsen <[EMAIL PROTECTED]>:

 




Disk tests should be at a fixed rate, not all you can do. That's NOT
realistic.
  

   


Not true; what you suggest is another thing to check entirely, and that
 

would 
   


be a valid benchmark too. What I'm interested in is what happens if you read
 


or write a DVD ISO image for example to your hard disk and what this does to
 


interactivity. This sort of reading or writing is not throttled in real
 


life.
   

Of course it is. At least the read. It's limited to the speed needed to 
either play (watch) the image or to burn it.
   



Ok we'll call it hair splitting. We do both. You read the file and I copy it.
Both happen in real life, and I plan to emulate both.



And that sounds exactly correct.

--
bill davidsen <[EMAIL PROTECTED]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

-
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: how to be a kernel developer ?

[Alejandro Bonilla]

> Hi
>
> I want to join the Kernel community and help in developing Linux
> kernel, I'm good in C,Perl and  not that good in C++
>
> is there any How-To page in how to help or how to join ? since I want
> to start in basic things

I can tell you one thing for sure. And that is that you will need to read a
lot and that includes the mailing list archives.

This exact question is made at least every 15 days. Did you google? You will
need to make that your Home Page.

.Alejandro

-
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: Merging relayfs?

[Tom Zanussi]

Steven Rostedt writes:
 > On Sun, 2005-07-17 at 10:52 -0500, Tom Zanussi wrote:
 > 
 > >  > 
 > >  > >  > - overwrite mode can be implemented via the buffer switch callback
 > >  > > 
 > >  > > The buffer switch callback is already where this is handled, unless
 > >  > > you're thinking of something else - one of the first checks in the
 > >  > > buffer switch is relay_buf_full(), which always returns 0 if the
 > >  > > buffer is in overwrite mode.
 > >  > 
 > >  > I mean, relayfs doesn't has to know about this, the client itself can 
 > > do 
 > >  > it (e.g. via helper functions).
 > > 
 > > In a previous version, we did something like having the client pass
 > > back a return value from the callback indicating whether or not to
 > > continue or stop.  I can try doing something like that instead again.
 > 
 > Tom,
 > 
 > I'm actually very much against this. Looking at a point of view from the
 > logdev device. Having a callback to know to continue at every buffer
 > switch would just be slowing down something that is expected to be very
 > fast. I don't see the problem with having an overwrite mode or not. Why
 > can't relayfs know this? It _is_ an operation of relayfs, and having it
 > pushed to the client would seem to make the client need to know more
 > about how relayfs works that it needs to.  Because, the logdev device
 > doesn't care about buffer switches.

I don't think it would slow anything down - it would be pretty much
the same code being executed as before e.g. the buffer_start()
callback for overwrite mode could look like this:

int buffer_start()
{
... 
return 1; // continue unconditionally
}

And for no-overwrite mode:

int buffer_start()
{
... 
return !relay_buf_full(buf); // continue if not full
}

Since the buffer start callback already returns the amount that's
supposed to be reserved at the start of the sub-buffer, I'd have to
make that an outparam instead, I guess, but it's basically the same
code handling the overwrite/no-overwrite condition.

Tom


-
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: Merging relayfs?

[Karim Yaghmour]

Roman Zippel wrote:
> The point is to design a simple and flexible relayfs layer, which means 
> not every possible function has to be done in the relayfs layer, as long 
> it's flexible enough to build additional functionality on top of it (for 
> which it can again provide some library functions).

I guess I just don't get the point here. Why cut something away if many
users will need it. If it's that popular that you're ready to provide a
library function to do it, then why not just leave it to boot? One of the
goals of relayfs is to avoid code duplication with regards to buffering
in general.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
-
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: Merging relayfs?

[Steven Rostedt]

On Mon, 2005-07-18 at 16:16 +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 18 Jul 2005, Steven Rostedt wrote:
> 
> > I'm actually very much against this. Looking at a point of view from the
> > logdev device. Having a callback to know to continue at every buffer
> > switch would just be slowing down something that is expected to be very
> > fast.
> 
> What exactly would be slowed down?
> It would just move around some code and even avoid the overwrite mode 
> check.

Yes, you're adding a jump to another function via a function pointer,
that would kill the cache line of execution, to avoid a simple check, or
some other way of handling it. Since I don't want to know the internals
of relayfs, the overwrite mode could be implemented in a more officient
way. Granted, this probably isn't much of a slowdown since the copying
of data would be much longer.

> 
> > I don't see the problem with having an overwrite mode or not. Why
> > can't relayfs know this?
> 
> The point is to design a simple and flexible relayfs layer, which means 
> not every possible function has to be done in the relayfs layer, as long 
> it's flexible enough to build additional functionality on top of it (for 
> which it can again provide some library functions).

The overwrite mode isn't that complex.  You don't want to make something
so flexible that it becomes more complex.  Assembly is more flexible
than C but I wouldn't want to code a lot with it.  A library function
for me is out of the question, since what I build on top of relayfs is
mostly in the kernel.  The overwrite mode would then have to be
implemented through another kernel activity.  I might as well keep my
own ring buffers and forget about using relayfs, and all my points in
which I argue for it being merged is mute.

-- Steve


-
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: Merging relayfs?

[Tom Zanussi]

Hareesh Nagarajan writes:
 > Tom Zanussi wrote:
 > > Roman Zippel writes:
 > >  > Hi,
 > >  > 
 > >  > On Thu, 14 Jul 2005, Tom Zanussi wrote:
 > >  > 
 > >  > > The netlink control channel seems to work very well, but I can
 > >  > > certainly change the examples to use something different.  Could you
 > >  > > suggest something?
 > >  > 
 > >  > It just looks like a complicated way to do an ioctl, a control file 
 > > that 
 > >  > you can read/write would be a lot simpler and faster.
 > > 
 > > You're right - in previous versions, we did use ioctl - we ended up
 > > using netlink as it seemed like least offensive option to most people.
 > > I'll try modifying the example code to use a control file or something
 > > like that instead though.
 > 
 > Having an ioctl() interface will definitely make things less 
 > complicated. Are the older versions which use ioctl available off the 
 > relayfs website?

Yes, the 'old relayfs' patches on the website implement ioctl.

Tom


-
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.13-rc3-mm1

[Joseph Fannin]

On Sat, Jul 16, 2005 at 09:32:49PM -0400,  wrote:
> On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> > 
>  
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>  
> > +suspend-update-documentation.patch
> > +swsusp-fix-printks-and-cleanups.patch
> > +swsusp-fix-remaining-u32-vs-pm_message_t-confusion.patch
> > +swsusp-switch-pm_message_t-to-struct.patch
> > +swsusp-switch-pm_message_t-to-struct-pmac_zilog-fix.patch
> > +swsusp-switch-pm_message_t-to-struct-ppc32-fixes.patch
> > +fix-pm_message_t-stuff-in-mm-tree-netdev.patch
> 

I needed this little patch too.  It's boot-tested; I have a MESH
controller.

Thanks!

-

diff -aurN linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c 
linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c
--- linux-2.6.13-rc3-mm1/drivers/scsi/mesh.c2005-07-16 01:46:44.0 
-0400
+++ linux-2.6.13-rc3-mm1_changed/drivers/scsi/mesh.c2005-07-18 
07:52:04.0 -0400
@@ -1766,7 +1766,7 @@
struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev);
unsigned long flags;
 
-   if (state == mdev->ofdev.dev.power.power_state || state < 2)
+   if (state.event == mdev->ofdev.dev.power.power_state.event || 
state.event < 2)
return 0;
 
scsi_block_requests(ms->host);
@@ -1781,7 +1781,7 @@
disable_irq(ms->meshintr);
set_mesh_power(ms, 0);
 
-   mdev->ofdev.dev.power.power_state = state;
+   mdev->ofdev.dev.power.power_state.event = state.event;
 
return 0;
 }
@@ -1791,7 +1791,7 @@
struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev);
unsigned long flags;
 
-   if (mdev->ofdev.dev.power.power_state == 0)
+   if (mdev->ofdev.dev.power.power_state.event == 0)
return 0;
 
set_mesh_power(ms, 1);
@@ -1802,7 +1802,7 @@
enable_irq(ms->meshintr);
scsi_unblock_requests(ms->host);
 
-   mdev->ofdev.dev.power.power_state = 0;
+   mdev->ofdev.dev.power.power_state.event = 0;
 
return 0;
 }


-- 
Joseph Fannin
[EMAIL PROTECTED]

"That's all I have to say about that." -- Forrest Gump.
-
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: Merging relayfs?

[Roman Zippel]

Hi,

On Mon, 18 Jul 2005, Steven Rostedt wrote:

> I'm actually very much against this. Looking at a point of view from the
> logdev device. Having a callback to know to continue at every buffer
> switch would just be slowing down something that is expected to be very
> fast.

What exactly would be slowed down?
It would just move around some code and even avoid the overwrite mode 
check.

> I don't see the problem with having an overwrite mode or not. Why
> can't relayfs know this?

The point is to design a simple and flexible relayfs layer, which means 
not every possible function has to be done in the relayfs layer, as long 
it's flexible enough to build additional functionality on top of it (for 
which it can again provide some library functions).

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] Fix cryptoapi deflate not handling PAGE_SIZE chunks.

[Nigel Cunningham]

Hi Herbert.

Here's a resend of a patch I'm using in Suspend2's new cryptoapi
support, which is needed for us to successfully compress pages using
deflate. It's along the lines of the existing fix in the decompression
code.

Regards,

Nigel

diff -ruNp 190-cryptoapi-deflate.patch-old/crypto/deflate.c 
190-cryptoapi-deflate.patch-new/crypto/deflate.c
--- 190-cryptoapi-deflate.patch-old/crypto/deflate.c2005-06-20 
11:46:49.0 +1000
+++ 190-cryptoapi-deflate.patch-new/crypto/deflate.c2005-07-04 
23:14:20.0 +1000
@@ -143,8 +143,15 @@ static int deflate_compress(void *ctx, c
 
ret = zlib_deflate(stream, Z_FINISH);
if (ret != Z_STREAM_END) {
-   ret = -EINVAL;
-   goto out;
+   if (!(ret == Z_OK && !stream->avail_in && !stream->avail_out)) {
+   ret = -EINVAL;
+   goto out;
+   } else {
+   u8 zerostuff = 0;
+   stream->next_out = 
+   stream->avail_out = 1; 
+   ret = zlib_deflate(stream, Z_FINISH);
+   }
}
ret = 0;
*dlen = stream->total_out;

-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

-
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/

LZF Cryptoapi support.

[Nigel Cunningham]

Hi again.

Here's another resend, this time adding an lzf cryptoapi module.

LZF is a very fast compressor which typically achieves approximately 50%
compression on a suspend image. The original author (Marc Alexander
Lehmann) donated it to Suspend2. I have converted it to cryptoapi with a
recent switch of Suspend2 to use cryptoapi.

Regards,

Nigel

 Kconfig  |7 +
 Makefile |1 
 lzf.c|  425 +++
 3 files changed, 433 insertions(+)
diff -ruNp 625-crypto-api-work.patch-old/crypto/Kconfig 
625-crypto-api-work.patch-new/crypto/Kconfig
--- 625-crypto-api-work.patch-old/crypto/Kconfig2005-06-20 
11:46:49.0 +1000
+++ 625-crypto-api-work.patch-new/crypto/Kconfig2005-07-06 
11:51:06.0 +1000
@@ -262,6 +262,13 @@ config CRYPTO_DEFLATE
  
  You will most probably want this if using IPSec.
 
+config CRYPTO_LZF
+   tristate "LZF compression algorithm"
+   depends on CRYPTO
+   help
+ This is the LZF algorithm. It is especially useful for Suspend2,
+ because it achieves good compression quickly.
+
 config CRYPTO_MICHAEL_MIC
tristate "Michael MIC keyed digest algorithm"
depends on CRYPTO
diff -ruNp 625-crypto-api-work.patch-old/crypto/lzf.c 
625-crypto-api-work.patch-new/crypto/lzf.c
--- 625-crypto-api-work.patch-old/crypto/lzf.c  1970-01-01 10:00:00.0 
+1000
+++ 625-crypto-api-work.patch-new/crypto/lzf.c  2005-07-06 22:10:55.0 
+1000
@@ -0,0 +1,425 @@
+/* 
+ * Cryptoapi LZF compression module.
+ *
+ * Copyright (c) 2004-2005 Nigel Cunningham <[EMAIL PROTECTED]>
+ *
+ * based on the deflate.c file:
+ * 
+ * Copyright (c) 2003 James Morris <[EMAIL PROTECTED]>
+ * 
+ * and upon the LZF compression module donated to the Suspend2 project with
+ * the following copyright:
+ *
+ * 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.
+ * Copyright (c) 2000-2003 Marc Alexander Lehmann <[EMAIL PROTECTED]>
+ * 
+ * Redistribution and use in source and binary forms, with or without modifica-
+ * tion, are permitted provided that the following conditions are met:
+ * 
+ *   1.  Redistributions of source code must retain the above copyright notice,
+ *   this list of conditions and the following disclaimer.
+ * 
+ *   2.  Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * 
+ *   3.  The name of the author may not be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ * 
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MER-
+ * CHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
+ * EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPE-
+ * CIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTH-
+ * ERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Alternatively, the contents of this file may be used under the terms of
+ * the GNU General Public License version 2 (the "GPL"), in which case the
+ * provisions of the GPL are applicable instead of the above. If you wish to
+ * allow the use of your version of this file only under the terms of the
+ * GPL and not to allow others to use your version of this file under the
+ * BSD license, indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by the GPL. If
+ * you do not delete the provisions above, a recipient may use your version
+ * of this file under either the BSD or the GPL.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct lzf_ctx {
+   void *hbuf;
+   char *local_buffer;
+   char *page_buffer;
+   unsigned int bufofs;
+   int first_call;
+};
+
+/*
+ * size of hashtable is (1 << HLOG) * sizeof (char *)
+ * decompression is independent of the hash table size
+ * the difference between 15 and 14 is very small
+ * for small blocks (and 14 is also faster).
+ * For a low-memory configuration, use HLOG == 13;
+ * For best compression, use 15 or 16.
+ */
+#define HLOG 14
+
+/*
+ * sacrifice some compression quality in favour of compression speed.
+ * (roughly 1-2% 

[PATCH] try_to_freeze call fixes.

[Nigel Cunningham]

Hi all.

Here are fixes for four try_to_freeze calls that are still (incorrectly)
using a parameter after the recent try_to_freeze() changes.

Regards,

Nigel

Signed-Off by: Nigel Cunningham <[EMAIL PROTECTED]>

 mips/kernel/irixsig.c  |2 +-
 mips/kernel/signal32.c |2 +-
 sh/kernel/signal.c |2 +-
 sh64/kernel/signal.c   |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)
diff -ruNp 202-more-try-to-freeze.patch-old/arch/mips/kernel/irixsig.c 
202-more-try-to-freeze.patch-new/arch/mips/kernel/irixsig.c
--- 202-more-try-to-freeze.patch-old/arch/mips/kernel/irixsig.c 2005-06-20 
11:46:44.0 +1000
+++ 202-more-try-to-freeze.patch-new/arch/mips/kernel/irixsig.c 2005-07-09 
20:41:44.0 +1000
@@ -178,7 +178,7 @@ asmlinkage int do_irix_signal(sigset_t *
if (!user_mode(regs))
return 1;
 
-   if (try_to_freeze(0))
+   if (try_to_freeze())
goto no_signal;
 
if (!oldset)
diff -ruNp 202-more-try-to-freeze.patch-old/arch/mips/kernel/signal32.c 
202-more-try-to-freeze.patch-new/arch/mips/kernel/signal32.c
--- 202-more-try-to-freeze.patch-old/arch/mips/kernel/signal32.c
2005-06-20 11:46:44.0 +1000
+++ 202-more-try-to-freeze.patch-new/arch/mips/kernel/signal32.c
2005-07-09 20:41:44.0 +1000
@@ -774,7 +774,7 @@ int do_signal32(sigset_t *oldset, struct
if (!user_mode(regs))
return 1;
 
-   if (try_to_freeze(0))
+   if (try_to_freeze())
goto no_signal;
 
if (!oldset)
diff -ruNp 202-more-try-to-freeze.patch-old/arch/sh/kernel/signal.c 
202-more-try-to-freeze.patch-new/arch/sh/kernel/signal.c
--- 202-more-try-to-freeze.patch-old/arch/sh/kernel/signal.c2005-06-20 
11:46:47.0 +1000
+++ 202-more-try-to-freeze.patch-new/arch/sh/kernel/signal.c2005-07-09 
20:41:45.0 +1000
@@ -579,7 +579,7 @@ int do_signal(struct pt_regs *regs, sigs
if (!user_mode(regs))
return 1;
 
-   if (try_to_freeze(0))
+   if (try_to_freeze())
goto no_signal;
 
if (!oldset)
diff -ruNp 202-more-try-to-freeze.patch-old/arch/sh64/kernel/signal.c 
202-more-try-to-freeze.patch-new/arch/sh64/kernel/signal.c
--- 202-more-try-to-freeze.patch-old/arch/sh64/kernel/signal.c  2005-06-20 
11:46:47.0 +1000
+++ 202-more-try-to-freeze.patch-new/arch/sh64/kernel/signal.c  2005-07-09 
20:41:45.0 +1000
@@ -697,7 +697,7 @@ int do_signal(struct pt_regs *regs, sigs
if (!user_mode(regs))
return 1;
 
-   if (try_to_freeze(0))
+   if (try_to_freeze())
goto no_signal;
 
if (!oldset)

-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

-
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 refrigerator() to try_to_freeze()

[Nigel Cunningham]

Hi.

This patch removes the few remaining direct invocations of the
refrigerator in 2.6.13-rc3. In drivers/media/video/msp3400.c, it also
shifts the call to after the remove_wait_queue; this seems to be the
more appropriate place.

Regards,

Nigel

Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>

 drivers/media/video/msp3400.c |4 +---
 drivers/net/irda/stir4200.c   |2 +-
 fs/jbd/journal.c  |2 +-
 fs/jfs/jfs_logmgr.c   |2 +-
 fs/jfs/jfs_txnmgr.c   |4 ++--
 fs/xfs/linux-2.6/xfs_buf.c|2 +-
 6 files changed, 7 insertions(+), 9 deletions(-)
diff -ruNp 
230-refrigerator-to-try_to_freeze.patch-old/drivers/media/video/msp3400.c 
230-refrigerator-to-try_to_freeze.patch-new/drivers/media/video/msp3400.c
--- 230-refrigerator-to-try_to_freeze.patch-old/drivers/media/video/msp3400.c   
2005-07-18 06:36:48.0 +1000
+++ 230-refrigerator-to-try_to_freeze.patch-new/drivers/media/video/msp3400.c   
2005-07-18 13:54:48.0 +1000
@@ -741,11 +741,9 @@ static int msp34xx_sleep(struct msp3400c
schedule_timeout(msecs_to_jiffies(timeout));
}
}
-   if (current->flags & PF_FREEZE) {
-   refrigerator ();
-   }
 
remove_wait_queue(>wq, );
+   try_to_freeze();
return msp->restart;
 }
 
diff -ruNp 
230-refrigerator-to-try_to_freeze.patch-old/drivers/net/irda/stir4200.c 
230-refrigerator-to-try_to_freeze.patch-new/drivers/net/irda/stir4200.c
--- 230-refrigerator-to-try_to_freeze.patch-old/drivers/net/irda/stir4200.c 
2005-07-18 06:36:51.0 +1000
+++ 230-refrigerator-to-try_to_freeze.patch-new/drivers/net/irda/stir4200.c 
2005-07-18 08:20:58.0 +1000
@@ -771,7 +771,7 @@ static int stir_transmit_thread(void *ar
 
write_reg(stir, REG_CTRL1, CTRL1_TXPWD|CTRL1_RXPWD);
 
-   refrigerator();
+   try_to_freeze();
 
if (change_speed(stir, stir->speed))
break;
diff -ruNp 230-refrigerator-to-try_to_freeze.patch-old/fs/jbd/journal.c 
230-refrigerator-to-try_to_freeze.patch-new/fs/jbd/journal.c
--- 230-refrigerator-to-try_to_freeze.patch-old/fs/jbd/journal.c
2005-07-18 06:36:59.0 +1000
+++ 230-refrigerator-to-try_to_freeze.patch-new/fs/jbd/journal.c
2005-07-18 13:54:47.0 +1000
@@ -175,7 +175,7 @@ loop:
 */
jbd_debug(1, "Now suspending kjournald\n");
spin_unlock(>j_state_lock);
-   refrigerator();
+   try_to_freeze();
spin_lock(>j_state_lock);
} else {
/*
diff -ruNp 230-refrigerator-to-try_to_freeze.patch-old/fs/jfs/jfs_logmgr.c 
230-refrigerator-to-try_to_freeze.patch-new/fs/jfs/jfs_logmgr.c
--- 230-refrigerator-to-try_to_freeze.patch-old/fs/jfs/jfs_logmgr.c 
2005-07-18 06:36:59.0 +1000
+++ 230-refrigerator-to-try_to_freeze.patch-new/fs/jfs/jfs_logmgr.c 
2005-07-18 13:54:47.0 +1000
@@ -2361,7 +2361,7 @@ int jfsIOWait(void *arg)
}
if (freezing(current)) {
spin_unlock_irq(_redrive_lock);
-   refrigerator();
+   try_to_freeze();
} else {
add_wait_queue(_IO_thread_wait, );
set_current_state(TASK_INTERRUPTIBLE);
diff -ruNp 230-refrigerator-to-try_to_freeze.patch-old/fs/jfs/jfs_txnmgr.c 
230-refrigerator-to-try_to_freeze.patch-new/fs/jfs/jfs_txnmgr.c
--- 230-refrigerator-to-try_to_freeze.patch-old/fs/jfs/jfs_txnmgr.c 
2005-07-18 06:36:59.0 +1000
+++ 230-refrigerator-to-try_to_freeze.patch-new/fs/jfs/jfs_txnmgr.c 
2005-07-18 13:54:47.0 +1000
@@ -2790,7 +2790,7 @@ int jfs_lazycommit(void *arg)
 
if (freezing(current)) {
LAZY_UNLOCK(flags);
-   refrigerator();
+   try_to_freeze();
} else {
DECLARE_WAITQUEUE(wq, current);
 
@@ -2989,7 +2989,7 @@ int jfs_sync(void *arg)
 
if (freezing(current)) {
TXN_UNLOCK();
-   refrigerator();
+   try_to_freeze();
} else {
DECLARE_WAITQUEUE(wq, current);
 
diff -ruNp 
230-refrigerator-to-try_to_freeze.patch-old/fs/xfs/linux-2.6/xfs_buf.c 
230-refrigerator-to-try_to_freeze.patch-new/fs/xfs/linux-2.6/xfs_buf.c
--- 230-refrigerator-to-try_to_freeze.patch-old/fs/xfs/linux-2.6/xfs_buf.c  
2005-07-18 06:37:01.0 +1000
+++ 230-refrigerator-to-try_to_freeze.patch-new/fs/xfs/linux-2.6/xfs_buf.c  
2005-07-18 13:54:48.0 +1000
@@ -1773,7 +1773,7 @@ xfsbufd(
do {
if (unlikely(freezing(current))) {
xfsbufd_force_sleep = 1;
-   refrigerator();
+   

[PATCH] Add missing tvaudio try_to_freeze.

[Nigel Cunningham]

Hi.

The .c gives Gerd Knorr as the maintainer of this file, but no email
address. The MAINTAINERS file doesn't have his name or make it clear who
owns the file. I haven't therefore been able to cc the maintainer.

Tvaudio lacks a refrigerator call. This patch fixes that.

Regards,

Nigel

Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>

 tvaudio.c |1 +
 1 files changed, 1 insertion(+)
diff -ruNp 234-tvaudio.patch-old/drivers/media/video/tvaudio.c 
234-tvaudio.patch-new/drivers/media/video/tvaudio.c
--- 234-tvaudio.patch-old/drivers/media/video/tvaudio.c 2005-07-18 
06:36:49.0 +1000
+++ 234-tvaudio.patch-new/drivers/media/video/tvaudio.c 2005-07-18 
08:20:58.0 +1000
@@ -285,6 +285,7 @@ static int chip_thread(void *data)
schedule();
}
remove_wait_queue(>wq, );
+   try_to_freeze();
if (chip->done || signal_pending(current))
break;
dprintk("%s: thread wakeup\n", i2c_clientname(>c));

-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

-
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.12-rc2 and as-iosched

[Jens Axboe]

On Mon, Jul 18 2005, Kenneth Parrish wrote:
> Randy> Need more info.
> 
> Greetings.  :)
> CONFIG_HZ_ changes the block device elevator time-out values -- didn't see.

I cannot reproduce here with cfq and HZ == 250, the jiffies <-> msec
conversions are working fine. Please provide a proper bug report, did
you change the values and not getting the expected back, or what is
going wrong??

-- 
Jens Axboe

-
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: Merging relayfs?

[Steven Rostedt]

On Sun, 2005-07-17 at 10:52 -0500, Tom Zanussi wrote:

>  > 
>  > >  > - overwrite mode can be implemented via the buffer switch callback
>  > > 
>  > > The buffer switch callback is already where this is handled, unless
>  > > you're thinking of something else - one of the first checks in the
>  > > buffer switch is relay_buf_full(), which always returns 0 if the
>  > > buffer is in overwrite mode.
>  > 
>  > I mean, relayfs doesn't has to know about this, the client itself can do 
>  > it (e.g. via helper functions).
> 
> In a previous version, we did something like having the client pass
> back a return value from the callback indicating whether or not to
> continue or stop.  I can try doing something like that instead again.

Tom,

I'm actually very much against this. Looking at a point of view from the
logdev device. Having a callback to know to continue at every buffer
switch would just be slowing down something that is expected to be very
fast. I don't see the problem with having an overwrite mode or not. Why
can't relayfs know this? It _is_ an operation of relayfs, and having it
pushed to the client would seem to make the client need to know more
about how relayfs works that it needs to.  Because, the logdev device
doesn't care about buffer switches.

-- Steve


-
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] I-pipe 2.6.12-v0.9-02

[Philippe Gerum]

The interrupt pipeline patch v0.9-02 has been released, fixing a latency 
spot and a bug in the deferred printk() mechanism.


A split version of the patch for x86, ppc32 and ia64 is available here: 
http://download.gna.org/adeos/patches/v2.6/ipipe/split/


Patch sequence to build a Linux 2.6.12 tree with I-pipe support:

http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2
http://download.gna.org/adeos/patches/v2.6/ipipe/ipipe-2.6.12-v0.9-02.patch

--

Philippe.
-
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: Volatile vs Non-Volatile Spin Locks on SMP.

[Joe Seigh]

Joe Seigh wrote:

For synchronization you need memory barriers in most cases and the only
way to get these is using assembler since there are no C or gcc intrinsics
for these yet.  For inline assembler, the convention seems to be to use
the volatile attribute, which I take as meaning no code movement across
the inline assembler code.  It if doesn't mean that then a lot of stuff
is broken AFAICT.



Usenet rule #1.  If you don't find something in the documentation, you
will find it after you post about it.  Volatile does seem to be documented
somewhat in the gcc docs
http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Extended-Asm.html#Extended-Asm

I was using "memory" in the clobber list as the main thing to keep optimization 
from
occurring across inline asm.  This seems to say that you also need to say 
"volatile" to
tell the compiler that you really mean it.

"If your assembler instructions access memory in an unpredictable fashion, add 
`memory' to the list of clobbered registers. This will cause GCC to not keep memory 
values cached in registers across the assembler instruction and not optimize stores or 
loads to that memory. You will also want to add the volatile keyword if the memory 
affected is not listed in the inputs or outputs of the asm, as the `memory' clobber does 
not count as a side-effect of the asm. If you know how large the accessed memory is, you 
can add it as input or output but if this is not known, you should add `memory'."

Also this needs to be looked at, i.e. does "sequence" mean in program order or 
with no interleaved
C statements.

"Similarly, you can't expect a sequence of volatile asm instructions to remain 
perfectly consecutive. If you want consecutive output, use a single asm. Also, GCC will 
perform some optimizations across a volatile asm instruction; GCC does not “forget 
everything” when it encounters a volatile asm instruction the way some other compilers 
do."

One of the problems with volatile in C was that the compiler could move code 
around the volatile
accesses and even accesses to other volatile variables.   This was a problem 
that Java had and
which they fixed with JSR-133 so you could actually do useful things with 
volatile in Java.  It's
just worse in C since C has nowhere as useful or clear definitions to work 
with.  The only
reason you can get away with something like

  do {
while (lock != 0);
  } while (!testandset());  // interlocked test and set

is the correctness of the code isn't affected by how the compiler treats
the test for lock != 0 as long as it terminates in a finite amount of time.  Or 
by the fact
that's not the best way to do a spin wait on hyperthreaded Intel processors.  
Intel
recommends you use a PAUSE intstruction in the wait loop.

Anyway it looks like I'll have to do a little more augury on the gcc docs. :)


--
Joe Seigh

-
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] Re: relayfs documentation sucks?

[Steven Rostedt]

On Sun, 2005-07-17 at 21:45 +0200, bert hubert wrote:
> On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
> 
> > It is racey - in this mode, there's nothing to keep the kernel from
> > writing as much as it wants before the user side has a chance to read
> > any of it.  The only way this can be used safely is to make sure the
> > kernel side isn't writing anything when the client is reading.  This
> > would be typical of a flight-recording usage i.e. kernel writes a
> > bunch of data continuously, then stops and allows the client to read
> > whatever's in there.
> 
> Or by numbering entries written out, when in flight-recording mode you
> wouldn't want to block the kernel.

Exactly!  I've written a logging device to record data in the kernel
that a printk can't help with.  I've used this in debugging inturrupts,
the scheduler, and high speed network packets. Where a printk to a
serial would just slow things down, and going to the network is too
expensive, and complex if you happen to be debugging the network. This
tool is called logdev (http://www.kihontech.com/logdev) and uses a ring
buffer that is like the relayfs overwrite mode. It can do printk like
records and when something goes wrong, I dump the buffer to the serial.
Or I have a user space program reading it from a device. I don't care
about anything that happened earlier, I want to only know what happened
up to the point I dumped the buffer.  Lately, I've been usuing this with
Ingo's RT patch, and when the system locks up, I dump the buffer, and it
shows quite nicely where the lockup occurred, and why.

With Tom's help, I also have a version that uses relayfs as a backend in
overwrite mode.  It's still a work in progress (so no web site yet!)
since there's some issues of using a singe buffer for multiple CPUs.
This helps in debugging race conditions since you need to see how events
interleave.

> 
> >  > In fact, it appears this might even happen in non-overwrite mode.
> > 
> > It shouldn't ever be able to happen in non-overwrite mode - if it
> > did, it would be a bug.  Can you be more specific as to how you see
> > this happening in this mode?
> 
> Yeah - you're right. The misunderstanding is because in both cases
> (overwrite and non-overwrite) data is lost, except that in one case you lose
> old data, and in the other new data.
> 
> It might be a good idea to document this as well.
> 
> Btw, I've already uncovered interesting things using relayfs, but I still
> don't see the case for having it merged :-)

The reason I would like to see this merged, so kernel hackers don't need
to constantly write there own logging buffers everytime you need to
debug a complex area of the kernel.

-- Steve


-
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/

ANNOUNCE: Driver for Rocky 4782E WDT and pls help

[Gyorgy Horvath]

Hi out there,

I am VERY SAD to announce a new driver for the
watchdog on Rocky 4782E2V processor card.

The architecture is very close to "Acquire WDT".
Effectivelly one or two additional line is needed, that allow
programming the timeout and properly kick the dog.

Writing a byte with the number of seconds to 0x0443
in the device open function will configure the timeout.
Ping needs a close before rearming.

I have compiled with CONFIG_WATCHDOG_NOWAYOUT and worked.

echo "1" > /dev/watchdog

15,14,13,...3,2,1,0 Booom.

The driver - rockywdt - can be downloaded from here

http://alpha.tmit.bme.hu/~horvaath/lk/rockywdt.tar.gz

The watchdog daemon can be pulled from the Debian pool.

CC-me on replies please.

P.S. Why I am so sad?
-

I'll tell you.

In the most recent application of SGA155D dual
SONET/SDH PCI adapter I have to pass thru POS
traffic - but hold on the packets for a while.

The things are now perfect. It can do 20..30 Mbytes/sec
but there is a very strange side effect - decribed below.

1. Metrics:  Moderate load

  - cca. 6 packets/second A-In, B-Out, B-In, A-Out - for each
  - cca. 4x5 Mbytes/sec R/W on the PCI bus, a Concorde can
easily land between my two DMA R/Ws.
  - packet size = 80 bytes
  - SGA155D generates interrupt in every 100 usec. Everything is
made here resulting 5% system load when idle, and 14% when fired.
  - Half of the RAM were stolen from Linux.
(mem= kernel parameter)
This range was requeset_mem_region-ed, then
ioremap-ped for bus mastering DMA transfer.
Actually 30 M is used.
(cat /proc/iomem shows 0c80-0e7f : sga155d0)
  - The granulity of the DMA transfer is 128 bytes (64 DWORDS) per turn.
The card reqests the PCI bus for each turn, then release it.
(Note that each packet can get thru in one turn)
  - Total of 16M small blocks were vmalloc-ed to keep track on
flows. This blocks has been kicked randomly upon each packet
arrival (2x6 times/sec) by the Interrupt routine.
  - Linux: Latest Debian woody
  - Kernel: kernel-source-2.4.18 (1..3)

2. Technique

  - On Rx - the card do everything. Once it fired - it fills the DMA
buffer, and once reach the end it restarts from the beginning.
There is no need for any kind of intervention from the PC.
It's progress is snooped through a stabilized regitser showing
where the DMA write address currently is.

  - The interrupt routine contact the vmalloc-ed blocks to schedule
the transmission.

  - On Tx - the interrupt routine writes a register with the
address of the packet to send. There is no flow control here either.
If the transmit queue (taking that register) is full, the
packet is then simply dropped and counted.

3. Good news

  - Every single inbound packet has been succesfully sent at
this load. No miss-sequence, no CRC, none... Seamless.

  - PCI slots behind the backplane's DECHIP PCI bridge
can perform up to this rate without packet loss.
At higher rates rx drops arises.

  - Slots routed directly from the CPU card well outperform this.

  - It can do for more than a day continously if unattended (see below).

4. Bad news

  - Issuing a simple ls -la / surelly causes instant death.

Instant mean -> not a single last breath. (no kernel printouts)
Death mean   -> plain dead. Only hard reset is working here.

5. The chalenge
  
  5.1 - Fire up the card

  - Apply the load
  - Issue - let say - lynx
  - Dead :-(

  5.2 - Fire up the card
  - Issue lynx - OK
  - Apply the load
  - Issue lynx again - OK :-O
  - Issue ls -la /
  - Dead :-S

  5.3 - Fire up the card
  - issue lynx - OK
  - issue ls -la / -OK
  - Apply the load
  - Issue pos sga155d0 -x (thats a control app)
  - Dead :-Z

  5.4 - Fire up the card
  - issue lynx - OK
  - Apply the load
  - issue lynx - OK
  - Sieze the load !!
  - issue ls -la / -OK !!
  - Reapply the load
  - Issue pos sga155d0 -x
  - Dead ;-/

  ... etc ...

6. Investigation

  At the very beginning I spent a lot of time finding a
  hardware bug. None. I feel it.  Although I noticed that
  someone (not me) takes control of the PC - time to time -
  for cca. 400..500 usec so that no DMA can occur.
  Therefore at at higher load some packet loss may occur.
  (I'will enlarge some FIFO's to bridge out this)
  
  I have gdb-d my 'crashing' controll app and found that a

  simple sscanf causes the sudden death.

  Moreover, I have applied a breakpoint to sscanf in the
  shared.o. Disassembling the the code causes sudden death
  at a given point. The code portions were not executed, just
  disassembled. What the hell is that?

  Besides the system is responsive and stable during that load
  - if I try things have been tried already before the load
  is applied. I am using ssh to control the box for example.

  This is the point where I gave up. I will modify the fire-up
  script so 

Re: 2.6.12 hangs on boot

[Andi Kleen]

Can you please test if this patch fixes it?

-Andi


Don't compare linux processor index with APICID

Fixes boot up lockups on some machines where CPU apic ids
don't start with 0

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

Index: linux/arch/x86_64/kernel/smpboot.c
===
--- linux.orig/arch/x86_64/kernel/smpboot.c
+++ linux/arch/x86_64/kernel/smpboot.c
@@ -211,7 +211,7 @@ static __cpuinit void sync_master(void *
 {
unsigned long flags, i;
 
-   if (smp_processor_id() != boot_cpu_id)
+   if (smp_processor_id() != 0)
return;
 
go[MASTER] = 0;



-
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.13-rc3 from today: No Toshiba ACPI module load?

[Horst von Brand]

I'm getting:
# modprobe toshiba_acpi
FATAL: Error inserting toshiba_acpi 
(/lib/modules/2.6.13-rc3/kernel/drivers/acpi/toshiba_acpi.ko): No such device

This is definitely a Toshiba M30 notebook with this.

On bootup I see:

ACPI: RSDP (v000 TOSHIB) @ 0x000f7a10
ACPI: RSDT (v001 TOSHIB 750  0x00970814 MASM 0x0611) @ 0x1ff63fd8
ACPI: FADT (v002 TOSHIB 750  0x20030101 MASM 0x6110) @ 0x1ff69d03
ACPI: SSDT (v001 TOSHIB A00070x00970814 MSFT 0x010e) @ 0x1ff69d87
ACPI: DBGP (v001 TOSHIB 750  0x00970814 MASM 0x6110) @ 0x1ff69fa4
ACPI: BOOT (v001 TOSHIB 750  0x00970814 MASM 0x0611) @ 0x1ff69fd8
ACPI: DSDT (v001 TOSHIB A00070x20030806 MSFT 0x010e) @ 0x
ACPI: PM-Timer IO Port: 0x1008

Anything else that might be useful?
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
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.6.13-rc3-mm1] connector: fix missing dependencies in Kconfig

[Guillaume Thouvenin]

Hello Andrew,

  This patch fixes missing dependencies in drivers/connector/Kconfig
file. We have to ensure that the dependencies of the selected variable
are fulfilled otherwise it can produce some undefined references
during the kernel compilation. This problem was reported by Adrian Bunk.

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

---

Index: linux-2.6.13-rc3-mm1/drivers/connector/Kconfig
===
--- linux-2.6.13-rc3-mm1.orig/drivers/connector/Kconfig 2005-07-18 
13:35:26.0 +0200
+++ linux-2.6.13-rc3-mm1/drivers/connector/Kconfig  2005-07-18 
13:37:43.0 +0200
@@ -12,6 +12,7 @@ config CONNECTOR
 
 config EXIT_CONNECTOR
bool "Enable exit connector"
+   depends on NET
select CONNECTOR
default y
---help---
@@ -23,6 +24,7 @@ config EXIT_CONNECTOR
 
 config FORK_CONNECTOR
bool "Enable fork connector"
+   depends on NET
select CONNECTOR
default y
---help---
-
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.6.12 (repost w/ corrected subject)] pci: restore BAR values in pci_enable_device_bars

[Grant Grundler]

On Tue, Jul 05, 2005 at 01:46:20PM -0400, John W. Linville wrote:
> On Sat, Jul 02, 2005 at 01:29:54AM -0600, Grant Grundler wrote:
> > On Thu, Jun 30, 2005 at 10:26:37PM -0400, John W. Linville wrote:
> 
> > > + /* Some devices lose PCI config header data during D3hot->D0
> > 
> > Can you name some of those devices here?
> > I just want to know what sort of devices need to be tested 
> > if this code changes in the future.
> 
> I don't really have a list.  The devices that brought this issue to
> my attention are a 3c905B and a 3c556B, both covered by the 3c59x
> driver.

John,
apologies for the late reply - been offline the past two weeks on holiday.

Just listing the two devices in a comment would be sufficient.

> According to section 5.4.1 of the "PCI BUS POWER MANAGEMENT INTERFACE
> SPECIFICATION, REV. 1.2", a device transitioning from D3hot to D0
> _may_ perform an internal reset, thereby going to "D0 Uninitialized"
> rather than "D0 Initialized".

Including the above paragraph in a comment would be a good thing.
I don't know if this spec is publicly available. But even if it is,
typically only a handful of people will be familiar enough with it
to know where to look in it.

> Since this behaviour is ratified by
> the spec, I think we need to accomodate it.

Yes - sounds reasonable to me too.

> A bit in the PMCSR register indicates how a device will behave in
> this regard.  We could have a test to only execute the BAR restoration
> for those devices that seem to need it.  I left that out because it
> seemed to add needless complexity.  In the meantime the patch has
> gotten bigger and more complex, so maybe that code doesn't make it
> any worse.  Do you want me to add that?

I think I'd keep it simpler until someone proves we need it.
I've read the rest of the thread and don't recall any such proof.

> 
> > 
> > > +transition.  Since some firmware leaves devices in D3hot
> > > +state at boot, this information needs to be restored.
> > 
> > Again, which firmware?
> > Examples are good since it makes it possible to track down
> > the offending devices for testing.
> 
> The Thinkpad T21 does this.  I don't know of any others specifically,
> but it seems like something laptop BIOSes would be likely to do.

That's fine - just listing the Thinkpad T21 in a comment is helpful.
If you happen to know the firmware version too, that would be even better.

> > The following chunk looks like it will have issues with 64-bit BARs:
> 
> As RMK pointed-out, this code is inspired by setup-res.c; specifically
> that in pci_update_resource.  I'd prefer not to blaze any new trails
> regarding 64-bit BAR support ATM... :-)

After thinking about this more, I'm convinced it's broken if a 64-bit BAR
is present on the PCI device. It doesn't matter if the MMIO value is
greater than 4GB or not. The problem is pci_dev->resource[i] does NOT
map 1:1 with PCI_BASE_ADDRESS_0+(i*4).

> So, is the current patch acceptable?

I don't think so. 64-bit BARs are just too common today.
One solution is to use a seperate variable to track the offset into
PCI config space. ie use "i" to walk through pci_dev->resource[]
and add "unsigned int pcibar_offset" to keep track of 32 vs 64-bit BARs.

> Or shall I add the check for the "no soft reset" bit in the PMCSR register?

I don't see why that's necessary.

thanks,
grant
-
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: RT and XFS

[Esben Nielsen]

On Thu, 14 Jul 2005, Christoph Hellwig wrote:

> On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
> > This reminds me of Documentation/stable_api_nonsense.txt . That no one
> > should really be dependent on a particular kernel API doing a particular
> > thing. The kernel is play dough for the kernel hacker (as it should be),
> > including kernel semaphores.
> > 
> > So we can change whatever we want, and make no excuses, as long as we
> > fix the rest of the kernel to work with our change. That seems pretty
> > sensible , because Linux should be an evolution. 
> 
> Daniel, get a fucking clue.  Read some CS 101 literature on what a semaphore
> is defined to be.  If you want PI singing dancing blinking christmas tree
> locking primites call them a mutex, but not a semaphore.
>

As a matter of fact I just finished what corresponds to your "CS 101" (I
study CS in spare time while having a full time job coding RT stuff):
To the one lecture I attended they talked about sempahores. They tought
students to use binary semphores for locking. Based on real-life
experience (and the Pathfinder story), I complained and told
them they ought to teach the students to use a mutex instead. They had no
clue "It is the same thing they said". Yes, a mutex can be implemented
just as a binary semaphore but the semantics of it is different. In RT the
difference is very important and even without-RT it is a good idea to
maintain the difference for readability and deadlock detection. If you
later on want to optimize the semaphore for what it is used for it is also
good to have maintained that information. It is a bit like discarding
the type information from you programs. You want to keep the type information 
even though the compilere end up producing the same code.

The kernel developer clearly have followed the same lectures and used
plain binary semaphores, sometimes calling the mutex sometimes semaphore.
I believe that the semaphore ought to be removed. Either use a mutex or
a completion. Far the most code is using a sempahore as either signalling 
- i.e. as a completion - or critical sections - i.e. as a mutex. If code
mixes the usage it is must likely very hard to read

Unfortunately, one of the goals of the preempt-rt branch is to avoid
altering too much code. Therefore the type semaphore can't be removed
there. Therefore the name still lingers ... :-(

Esben



-
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/

Commands available for [EMAIL PROTECTED]

[bug-wranglers+owner]

Hello,

There exists the following options:

To unsubscribe send a mail to:

[EMAIL PROTECTED]

To subscribe to the digest of this list send a mail to:

[EMAIL PROTECTED]

To subscribe to the nomail version of this list send a mail to:

[EMAIL PROTECTED]

The nomail version of a list means that you are reckognized as a
subscriber, but will not get any mails to the list. Useful when it's
necessary to post from several emailaddresses to a subscribers only list.

For retrieval of message number N in the archive send a mail to

[EMAIL PROTECTED]

To send a mail to the list owner, send a mail to:

[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: [RFD] FAT robustness

[Paulo Marques]

Hiroyuki Machida wrote:

[...]
 Q3 : I'm not sure JBD can be used for FAT improvements.   Do you 
have any comments ?


I might not be the best person to answer this, but this just seems so 
obvious:


If you plan to let a recently hot-unplugged device to be used in another 
OS that doesn't understand your journaling extensions, your disk will be 
corrupted.


If this is supposed to work only on OS's that understand your journaling 
extensions, then there are much better filesystems out there with 
journaling already.


You might be able to reduce the size of the time window where hot 
removing the media will cause problems, like writting all the data first 
and update the metadata in as few operations as possible. But that just 
reduces the probability of data corruption. It doesn't eliminate it at all.


--
Paulo Marques - www.grupopie.com

It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
-
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][PATCH - 1/12] NTP cleanup: Move NTP code into ntp.c

[Pavel Machek]

Hi!

>   This patch moves the generic NTP code from time.c and timer.c into
> ntp.c. It makes most of the NTP variables static providing more
> understandable interfaces like ntp_synced() and ntp_clear(). 
>   
> Since some of the newly made static variables are used in arch generic
> code, this patch alone will not compile. Thus this patch requires part 2
> of the series which fixes the arch specific uses of the newly static
> variables.
> 
> Any comments or feedback would be greatly appreciated.
> 
> thanks
> -john
> 

> diff --git a/kernel/ntp.c b/kernel/ntp.c
> new file mode 100644
> --- /dev/null
> +++ b/kernel/ntp.c
> @@ -0,0 +1,490 @@
> +/
> +* linux/kernel/ntp.c
> +*
> +* NTP state machine and time scaling code.
> +*
> +* Code moved from kernel/time.c and kernel/timer.c
> +* Please see those files for original copyrights.
> +*
> +* 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.
> +*
> +* This program is distributed in the hope that it will be useful,
> +* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +* GNU General Public License for more details.
> +*
> +* You should have received a copy of the GNU General Public License
> +* along with this program; if not, write to the Free Software
> +* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> +*
> +* Notes:
> +*
> +* Hopefully you should never have to understand or touch
> +* any of the code below. but don't let that keep you from trying!
 ~~~ should be "," ?

> +* This code is loosely based on David Mills' RFC 1589 and its
> +* updates. Please see the following for more details:
> +*  http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt
> +*  http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf
> +*
> +* NOTE:  To simplify the code, we do not implement any of
> +* the PPS code, as the code that uses it never was merged.
> +* [EMAIL PROTECTED]
> +*
> +*/
> +
> +#include 
> +#include 
> +#include 
> +
> +#ifdef CONFIG_TIME_INTERPOLATION
> +void time_interpolator_update(long delta_nsec);
> +#else
> +#define time_interpolator_update(x)

do {} while (0) is safer...

> + result = time_state;   /* mostly `TIME_OK' */
> +
> + /* Save for later - semantics of adjtime is to return old value */
> + save_adjust = time_next_adjust ? time_next_adjust : time_adjust;
> +
> +#if 0/* STA_CLOCKERR is never set yet */
> + time_status &= ~STA_CLOCKERR;   /* reset STA_CLOCKERR */
> +#endif

Please remove deleted code completely.

> +/**
> + * ntp_synced - Returns 1 if the NTP status is not UNSYNC
> + *
> + */
> +int ntp_synced(void)
> +{
> + return !(time_status & STA_UNSYNC);
> +}

Should this be inline in header somewhere?

Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
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] Preserve hibenate-system-image on startup

[Pavel Machek]

Hi!

> We are now investigating fast startup/shutdown using
> 2.6 kernel PM functions.
> 
> An attached patch enables kernel to preserve system image
> on startup, to implement "Snapshot boot"[EMAIL PROTECTED] wrote:
> Conventionally system image will be broken after startup.
> 
> Snapshot boot uses un-hibernate from a permanent system image for
> startup. During shutdown, does a conventional shutdown without
> saving a system image.
> 
> We'll explain concept and initial work at OLS. So if you have
> interest, we can talk with you at Ottawa.

Interesting

> +config PRESERVE_SWSUSP_IMAGE
> + bool "Preserve swsuspend image"
> + depends on SOFTWARE_SUSPEND
> + default n
> + ---help---
> +   Useally boot with swsup destories the swsusp image.
> +   This function enables to preserve swsup image over boot cycle. 
> +   Default behavior is not chaged even this configuration turned on.
> +
> +   To preseve swsusp image, specify following option to command line;
> +
> + prsv-img

You are missing "eeeae" here.

> +}
> +
> +/**
> + * swsusp_swpoff -  Turn off swap and set signature for swsusp image
 ~~
missing "a".

In general, the patch looks a bit too long, given it only needs to
comment out one write...
Pavel

-- 
teflon -- maybe it is a trademark, but it should not be.
-
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.13-rc3-mm1

[Pavel Machek]

Hi!

> I'm getting this (on ppc32, though I don't think it matters):
> 
>   CC  drivers/video/chipsfb.o
> drivers/video/chipsfb.c: In function `chipsfb_pci_suspend':
> drivers/video/chipsfb.c:465: error: invalid operands to binary ==
> drivers/video/chipsfb.c:467: error: invalid operands to binary !=
> make[3]: *** [drivers/video/chipsfb.o] Error 1
> make[2]: *** [drivers/video] Error 2
> make[1]: *** [drivers] Error 2
> make[1]: Leaving directory
> `/usr/src/linux-ctesiphon/linux-2.6.13-rc3-mm1'
> make: *** [stamp-build] Error 2
> 
> The above-quoted patches seem to be the culprit, but my feeble
> attempts at making a patch didn't work out.

Should be easy. Just add .event at right places...

> But I can't help but notice that every linux-suspend HOWTO tells
> you to patch in swsusp2 as a first step -- the consensus seems to be
> that it you want clean and conservative code, use swsusp1; if you want
> suspending to *work*, use swsusp2.  How many people are actually able
> to make use of swsusp1?  Is anyone testing it besides Mr. Machek?

SuSE ships it in production, so I believe we have at least as many
users as suspend2...
Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
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: RT and XFS

[Esben Nielsen]

On Fri, 15 Jul 2005, Daniel Walker wrote:

> On Fri, 2005-07-15 at 12:23 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> > 
> > > PI is always good, cause it allows the tracking of what is high 
> > > priority , and what is not .
> > 
> > that's just plain wrong. PI might be good if one cares about priorities 
> > and worst-case latencies, but most of the time the kernel is plain good 
> > enough and we dont care. PI can also be pretty expensive. So in no way, 
> > shape or form can PI be "always good".
> 
> I don't agree with that. But of course I'm always speaking from a real
> time perspective . PI is expensive , but it won't always be. However, no
> one is forcing PI on anyone, even if I think it's good ..
> 

Is PI needed? If you use a mutex to protect a critical area you are
destroying the strict meaning of priorities if the mutex doesn't have PI:
Priority inversion can effectively make the high priority task low
priority in that situation and postpone it's execution indefinitely. 
For RT applications that is clearly unacceptable.

One can argue that for non-RT tasks priorities aren't supposed to be that 
rigid as for RT tasks, anyway. Therefore it doesn't matter so much.
But as I read the comments in sched.c a nice -20 task have to preempt any
nice 0 task no matter how much a cpu-hog it is. If it happens to share a
critical section with a nice +19 task, priority inversion will
occationally destroy that property. If we disregard the costs of PI, PI is
thus a good thing.

But how expensive is PI? Ofcourse there is an overhead in doing
the calculations. Ingo's implementation can be optimized quite a bit once
things are settled but it will always be many times more expensive than a
raw spin-lock. But is it much more expensive than a plain binary
semaphore?

If the is no congestion on a mutex the PI code will not be called at all.
On UP, the only occation where congestion can occur is when a low
priority task is preempted by a higher priority task while it has the
mutex. So let us look at the expensive part where the high priority task
tries to grab the mutex:

With PI: The owner have to be boosted, an immediate task switch have to
take place, the owner runs to the unlock operation and it set down in
priority, whereafter there is a task-switch again to the highpriority
task.

Without PI: The owner waits and there is a task switch to some thread
which might not be the owner but often is. When the owner eventually
unlocks the mutex it will be follow by a task-switch - because congestion
can only occur when the task trying to get the task preempts and thus have
higher priority than the owner.

The number of task switches are thus the same with and without PI!

And then there is the cache issue: When other tasks gets scheduled in the
priority inversion case the data being protected can be flushed from the
cache while they are running. With PI the CPU continues to work with the
same data - and most often in the same code module. I.e. there is a higher
chance that the instruction and data cache contains the right data.

Thus in the end it all depends on how cheaply the PI calculations can be
made.

Esben

> Daniel
> 
> -
> 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: [PATCH] signed char fixes for scripts

[Paulo Marques]

Paulo Marques wrote:

Sam Ravnborg wrote:
[...]

Also this patch seems relative small compared to the others floating
around to cure signed warnings in scripts/
Does this really fix all of them or only a subset of the warnings?


Well, current -linus already has a patch from me to change the 

^^
I meant -mm... :P

--
Paulo Marques - www.grupopie.com

It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
-
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.12 hangs on boot

[Alexander Y. Fomichev]

On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
> > I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
> > GHz [ MoBo: Intel E7520, intel 82801 ]
> > but kernel hangs on boot right after records:
> >
> > Booting processor 2/1 rip 6000 rsp 8100023dbf58
> > Initializing CPU#2
>
> Hmm.. Since you seem to be a git user, maybe you could try the git
> "bisect" thing to help narrow down exactly where this happened (and help
> test that thing too ;).

[skiped]

Ok, as i can see  [and as Andi guessed 
http://bugme.osdl.org/show_bug.cgi?id=4792] 
issue have been introduced by new TSC sync algorithm
git id: dda50e716dc9451f40eebfb2902c260e4f62cf34.

And, yes, seems like it depends of timings...
In my case kludge with insertion of low delay (e.g. printk) between 
cpu_set/mb and tsc_sync_wait() makes kernel bootable.

diff -urN b/arch/x86_64/kernel/smpboot.c a/arch/x86_64/kernel/smpboot.c
--- b/arch/x86_64/kernel/smpboot.c  2005-07-17 21:55:55.0 +0400
+++ a/arch/x86_64/kernel/smpboot.c  2005-07-17 21:57:56.0 +0400
@@ -451,6 +451,7 @@
cpu_set(smp_processor_id(), cpu_online_map);
mb();
 
+   printk(KERN_INFO "We're still here!\n");
/* Wait for TSC sync to not schedule things before.
   We still process interrupts, which could see an inconsistent
   time in that window unfortunately. */ 

-- 
Best regards.
Alexander Y. Fomichev <[EMAIL PROTECTED]>
Public PGP key: http://sysadminday.org.ru/gluk.asc
-
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: Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.

[Alan Cox]

On Llu, 2005-07-18 at 10:12 +0530, vamsi krishna wrote:
> I was searching a lot about work on this, and found your reply where
> you say that we can increase the virtual address space by mmaping and
> munmaping programatically ourself.

Its something a few giant applications do with data sets and the trick
of using shared memory segments works on most Linux or Unixlike systems.
It's almost a historical note now. With 64bit processors its no longer
worth the pain

-
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] i386: Selectable Frequency of the Timer Interrupt

[Maciej W. Rozycki]

On Fri, 15 Jul 2005, Venkatesh Pallipadi wrote:

> Well.. I tried a patch to do the broadcast thing couple of months ago and 
> failed to convince everyone :(.

 I must have missed the patch -- but was the change unconditional or 
affecting only broken systems?  And how such systems were determined?

> Further, it doesn't work well if you want to exclude some CPUs from the 
> list of recievers. Logical destination is simple only for less than 8 
> CPUs. Beyond that with clustered or physical configuration it is 
> difficult.

 Well, I've thought the number of bits for LDR has been reexpanded at one 
point (it had been 32 originally with the 82489DX and then shrank to 8 
with the Pentium integrated APIC) -- it must have been something else...

 Anyway, for this you should just need a single bit as, quoting APIC 
documentation:

 "When the message addresses the destination using logical addressing 
scheme each Local Unit in the ICC bus compares the logical address in the 
interrupt message with its own Logical Destination Register.  If there is 
a bit match (i.e., if at least one of the corresponding pair of bits 
match) this local unit is selected for delivery."

Thus you could make, say, bit 31 of LDR the "timer bit", set it in all 
local APIC units and send timer interrupts in the Fixed delivery mode 
using a logical destination address with only bit 31 set.  You could then 
exclude processors from delivery by clearing bit 31 of LDR as needed.  It 
could probably be applied to addresses within clusters, too, though space 
there is a bit tight.

 None of such hassle should be needed in reality, though -- I presume the 
only broken systems are uniprocessor ones with the HT feature as real SMP 
systems need to have their APICs enabled all the time to be able to accept 
IPIs if nothing else.  As UP systems with HT have only two processors 
logically, there is no problem with using the logical destination mode as 
currently implemented.

  Maciej
-
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] signed char fixes for scripts

[Paulo Marques]

Sam Ravnborg wrote:

On Fri, Jul 15, 2005 at 10:14:43PM +, J.A. Magallon wrote:


On 07.16, J.A. Magallon wrote:
[...]
This time I did not break anything... and they shut up gcc4 ;)


Thanks.
Can you please resend with proper changelog and signed-off-by.
Diff should be done on top of latest -linus preferable.
Also this patch seems relative small compared to the others floating
around to cure signed warnings in scripts/
Does this really fix all of them or only a subset of the warnings?


Well, current -linus already has a patch from me to change the 
compression scheme that also fixes most of the signedness problems. The 
ones below escaped me because my gcc3.3.2 didn't complain about them 
even with all the -W[xxx] switches I could find.


This takes a big hunk out of previous patches I've seen, so that might 
explain the difference.


--
Paulo Marques - www.grupopie.com

It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
-
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: Kernel Panic: VFS cannot open a root device

[Ed Tomlinson]

On Sunday 17 July 2005 22:46, Fawad Lateef wrote:
> I saw this prob when my boot device/partition in the bootloader config
> was wrong or the filesystem of my root partition is not compiled as a
> kernel image rather compiled as module, so plz try to solve this prob
> by selecting your desired filesystem in kernel configuration as Y
> rather than M .. I hope this will work

One further tip.  Make your root FS's type the only one that is not a module.
Once you have it booting then, if you want, flip other FSes to in kernel.

Ed Tomlinson
-
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/

shared subtrees implementation writeup

[Miklos Szeredi]

Thanks for the writeup, it helps to understand things a bit better.
However I still don't understand a few things:


> Section 1. mount:
> 
>   to begin with we have a the following mount tree 
> 
>root
> / /  \  \ \
>/  t1  t2 \  \ 
>  t0   t3 \
>   t4
> 
>   note: 
>   t0, t1, t2, t3, t4 all contain mounts.
>   t1 t2 t3 are the slave of t0. 
>   t4 is the slave of t2.
>   t4 and t3 is marked as shared.
> 
>   The corresponding propagation tree will be:
> 
>   p0
> /   \
>p1   p2
>/ 
>p3
> 
> 
>   ***
> p0 contains the mount t0, and contains the slave mount t1
> p1 contains the mount t2
> p3 contains the mount t4
> p2 contains the mount t3
> 
> NOTE: you may need to look at this multiple time as you try to
>   understand the various scenarios.
>   ***

Why you have p2 and p3?  They contain a single mount only, which could
directly be slaves to p0 and p1 respectively.  Does it have something
to do with being shared?

BTW, is there a reason not to include the pnode info in 'struct
vfsmount'?  That would simplify a lot of allocation error cases.

>   The key point to be noted in the above set of operations is:
>   each pnode does three different operations corresponding to each stage.
> 
>   A. when the pnode is encountered the first time, it has to create
>   a new pnode for its child mounts.
>   B. when the pnode is encountered again after it has traversed down
>  each slave pnode, it has to associate the slave pnode's newly created
>  pnode with the pnode's newly created pnode.
>   C. when the pnode is encountered finally after having traversed through
>   all its slave pnodes, it has to create new child mounts
>   for each of its member mounts.

Now why is this needed?  Couldn't each of these be done in a single step?

I still can't see the reason for having these things done at different
stages of the traversal.

Thanks,
Miklos
-
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] i386: Selectable Frequency of the Timer Interrupt

[Maciej W. Rozycki]

On Fri, 15 Jul 2005, Andi Kleen wrote:

> >  That's like scratching your left ear with your right hand -- broadcasting 
> > that external timer interrupt in the first place is more straightforward.  
> > If you want to exclude CPUs from the list of receivers, just use the 
> > logical destination mode appropriately.
> 
> The problem with that is that it would need regular synchronizations
> of all CPUs to coordinate this.   Not good for scalability and I 
> believe the fundamentally wrong way to do this.

 What to you mean by "regular synchronizations of all CPUs?"  And how is a 
broadcasted external timer interrupt different from a unicasted one 
redistributed further via an all-but-self IPI, except from removing an 
unnecessary burden from the CPU targeted by the unicast interrupt?

  Maciej
-
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/