Re: Why does reading from /dev/urandom deplete entropy so much?

[Jon Masters]

On Wed, 2007-12-05 at 09:49 -0500, Theodore Tso wrote:
> On Wed, Dec 05, 2007 at 08:26:19AM -0600, Mike McGrath wrote:
> >
> > Ok, whats going on here is an issue with how the smolt RPM installs the 
> > UUID and how Fedora's Live CD does an install.  It's a complete false alarm 
> > on the kernel side, sorry for the confusion.
> 
> BTW, You may be better off using "uuidgen -t" to generate the UUID in
> the smolt RPM, since that will use 12 bits of randomness from
> /dev/random, plus the MAC, address and timestamp.  So even if there is
> zero randomness in /dev/random, and the time is January 1, 1970, at
> least the MAC will contribute some uniqueness to the UUID.

I haven't checked how uuidgen uses the MAC, but I would suggest that
that is not something Fedora should jump at doing - although it would
help ensure unique UUIDs, it also contributes to the tinfoil hat
responses that usually come up with things like smolt.

Jon.


--
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.24-rc4-git5: Reported regressions from 2.6.23

[Fabio Comolli]

Hi.

On Dec 8, 2007 3:40 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> This message contains a list of some regressions from 2.6.23 which have been
> reported since 2.6.24-rc1 was released and for which there are no fixes in the
> mainline that I know of. If any of them have been fixed already, please let me
> know.
>
> If you know of any other unresolved regressions from 2.6.23, please let me 
> know
> either and I'll add them to the list.



> Subject : Battery shows up twice in kpowersave
> Submitter   : Rolf Eike Beer <[EMAIL PROTECTED]>
> References  : http://bugzilla.kernel.org/show_bug.cgi?id=9494
> Handled-By  : Alexey Starikovskiy <[EMAIL PROTECTED]>
> Patch   :
>

I don't think that this is a regression: I reported on RedHat bugzilla
when I switched from F7 to F8 and I was using 2.6.23.8 at that time.
It looks to me an HAL regression, but of course I may be wrong :-) as
the reported bisected to a bad commit.

https://bugzilla.redhat.com/show_bug.cgi?id=373041

By the way, I now switched to Fedrora Rawhide with a 2.6.24-rc4-git5
custom kernel and Gnome desktop and the problem is still present, even
with gnome-power-manager.

Hope this helps.
Regards,
Fabio
--
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 guidance

[Martin Langhoff]

On Dec 1, 2007 7:50 PM, Al Boldi <[EMAIL PROTECTED]> wrote:
> Not sure what you mean by operationally transparent?  It would be transparent
> for the updating client,  and the rest of the git-users would need to wait
> for the commit from the updating client; which is ok, as this transparency
> is not meant to change the server-side git-update semantic.

I guess what he means is that when your write to the file -- from your
editor -- it can't be considered a commit. During an editing session
you might write a dozen times, only to commit it once you are happy
(that it compiles, passes tests, etc).

> Sure, you wouldn't want to change the git-engine update semantics, as that
> sits on the server and handles all users.  But what the git model is
> currently missing is a client manager.  Right now, this is being worked
> around by replicating the git tree on the client, which still doesn't
> provide the required transparency.

If you want a dumb-ish client CVS-style, you can try git-cvsserver.
But the git model is definitely superior -- "replicating the tree on
the client" is not a workaround but a central strategy.

Have you used git and other DSCMs much? From your writing, it sounds
like you may have misunderstood how some of the principles of git work
out in practice.

cheers,


m
--
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] V4L/DVB: SAA7134: Enable remote control support for Avermedia M102

[Albert Graham]

From: Albert Graham <[EMAIL PROTECTED]>

Signed-off-by: Albert Graham <[EMAIL PROTECTED]>

[PATCH] V4L/DVB: SAA7134: Enable remote control support for Avermedia M102

This patch enabled the IR remote control for the Avermedia M102 (card=110), 
which appears to be the same IR as the already supported device on the 
Avermedia AVerTV GO 007 FM (card=57) model, the code is two one liners which enable the

IR for this device (subsystem: 1461:f31e)

I understand that this IR RC was previously supported by the lirc_gpio which is 
no longer
supported in the kernel. The dmesg below show the device being detected and it 
works a expected.


dmesg output:

saa7133[0]: found at :0a:04.0, rev: 209, irq: 23, latency: 64, mmio: 
0xb3006000
saa7133[0]: subsystem: 1461:f31e, board: Avermedia M102 [card=110,autodetected]
saa7133[0]: board init: gpio is 7f0

---> input: saa7134 IR (Avermedia M102) as /class/input/input8 <-

saa7133[0]: i2c eeprom 00: 61 14 1e f3 ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 20: ff d1 fe ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 1-004b: chip found @ 0x96 (saa7133[0])
tuner 1-004b: setting tuner address to 61
tuner 1-004b: type set to tda8290+75
firewire_core: created new fw device fw0 (0 config rom retries, S400)
tuner 1-004b: setting tuner address to 61
tuner 1-004b: type set to tda8290+75

lspci -v:

0a:04.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video 
Broadcast Decoder (rev d1)
   Subsystem: Avermedia Technologies Inc Unknown device f31e
   Flags: bus master, medium devsel, latency 64, IRQ 23
   Memory at b3006000 (32-bit, non-prefetchable) [size=2K]
   Capabilities: [40] Power Management version 2

uname -r:
2.6.23.8-63.local.fc8



diff -uNrp a/drivers/media/video/saa7134/saa7134-cards.c 
b/drivers/media/video/saa7134/saa7134-cards.c
--- a/drivers/media/video/saa7134/saa7134-cards.c   2007-10-09 
21:31:38.0 +0100
+++ b/drivers/media/video/saa7134/saa7134-cards.c   2007-12-08 
05:38:17.0 +
@@ -4440,6 +4440,7 @@ int saa7134_board_init1(struct saa7134_d
   break;
   case SAA7134_BOARD_AVERMEDIA_M102:
   /* enable tuner */
+   dev->has_remote = SAA7134_REMOTE_GPIO;
   saa_andorl(SAA7134_GPIO_GPMODE0 >> 2,   0x8c040007, 0x8c040007);
   saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x0c0007cd, 0x0c0007cd);
   break;
diff -uNrp a/drivers/media/video/saa7134/saa7134-input.c 
b/drivers/media/video/saa7134/saa7134-input.c
--- a/drivers/media/video/saa7134/saa7134-input.c   2007-10-09 
21:31:38.0 +0100
+++ b/drivers/media/video/saa7134/saa7134-input.c   2007-12-08 
05:38:17.0 +
@@ -246,6 +246,7 @@ int saa7134_input_init1(struct saa7134_d
   case SAA7134_BOARD_AVERMEDIA_STUDIO_307:
   case SAA7134_BOARD_AVERMEDIA_STUDIO_507:
   case SAA7134_BOARD_AVERMEDIA_GO_007_FM:
+case SAA7134_BOARD_AVERMEDIA_M102:
   ir_codes = ir_codes_avermedia;
   mask_keycode = 0x0007C8;
   mask_keydown = 0x10;

--- END -




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

Re: x86_64 dynticks not working prev: cpuidle, dynticks compatible or no?

[Ed Sweetman]

Ed Sweetman wrote:

Robert Hancock wrote:

Ed Sweetman wrote:
System is idle now, previously it was doing something i couldn't 
halt at the time.  I'm looking at "Local timer interrupts" in the 
"Loc:" section of /proc/interrupts.
Across 1 second while the system is pretty much idle, i still get 
300 interrupts. My HZ variable is set to 300 in the kernel config, 
so this is expected but I was under the assumption that 
dynticks/tickless being compiled in would cause that to be much lower.


Am I reading the wrong section of /proc/interrupts  to verify if 
dynticks is working or not? Again, i see no difference in cpu temp 
at all.


Try running powertop ( http://www.lesswatts.org/projects/powertop/ ) 
and see what it reports.


I don't think dynticks will generally save huge amounts of power on a 
typical desktop machine. The big gains come from being able to stay 
in deep sleep C-states (C2/C3) for longer periods of time, but most 
desktop machines only enable sleep states down to C1.


I tried running powertop, it complains about not having timer 
statistics, I looked throughout the kernel config for a timer stat 
option, but can't find one.


I didn't have hpet compiled in, i'm not sure if this is required but a 
lot of places seem to suggest hpet and high precision timer and 
tickless be compiled together.  I also disabled cpuidle and i'll 
reboot and try that.


read too fast through the powertop error message.  timer stat info is in 
kernel_debug option.  Which i did not compile in this latest kernel 
again.   Sorry. 

Though, with hpet and such, i still see no measurable difference or any 
sort of evidence that ticks are being skipped (comparing 
/proc/interrupts across sleep 1s;)







In case it helps, this is an athlon64 x2 with apic functioning and 
both cores active in 64bit mode. dmesg is below.

not related :
Some additional notes:  it87 is my lm_sensor, it doesn't work in 
this kernel, yet it did in 2.6.22.  Perhaps enabling high precision 
timers changed something in acpi land.


I enabled tcp dma offloading in this kernel, i get debugging output 
related to it, error is at the last line.  No corruption or 
otherwise bad behavior.   Transferring via cifs at 9.7MB/sec 
"incoming" took about 15% of one cpu...  I never bothered to check 
if that is the norm but i suspect i'll be removing that feature as 
it seems to not play nice with the kernel.






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

[Valdis . Kletnieks]

On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:

> It probably goes without saying, that gitfs should have some basic 
> configuration file to setup its transparent behaviour

But then it's not *truly* transparent, is it?

And that leaves another question - if you make a config file that excludes
all the .o files - then what's backing the .o files?  Those data blocks need
to be *someplace*.  Maybe you can do something ugly like use unionfs to
combine your gitfs with something else to store the other files...

But at that point, you're probably better off just creating a properly
designed versioning filesystem.


pgprg99Rd8pc6.pgp
Description: PGP signature

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

[Bob Tracy]

Kay Sievers wrote:
> Is the udev daemon (still) running while it fails?

Yes, and there's something else I forgot to mention that may be
significant...  For the bad case, in addition to udevd, "ps -ef"
shows a "sh -e /lib/udev/net.agent" running with a PPID of 1.  This
process doesn't exit until I reboot.  If this is normal under the
circumstances, please disregard.

-- 

Bob Tracy  |  "They couldn't hit an elephant at this dist- "
[EMAIL PROTECTED]   |   - Last words of Union General John Sedgwick,
   |  Battle of Spotsylvania Court House, U.S. Civil War

--
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.24-rc4-mm1 and Very Slow PCMCIA Compact Flash

[Zan Lynx]

On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote:
> On Fri, 07 Dec 2007 23:09:43 +
> Zan Lynx <[EMAIL PROTECTED]> wrote:
[cut] 
> > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I
> > > > only get read rates of 1.6 MB/s.  When it used to work in 2.6.20 I got
> > > > at least 16 MB/s.  The card itself is capable of 30+ in the USB-2
> > > > reader.
[cut]
> Maybe pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards.patch?
> 
> Could you try a `patch -R' of the below?
> 
> 
> From: Alan Cox <[EMAIL PROTECTED]>
> 
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
> 
>  drivers/ata/pata_pcmcia.c |   31 +--
>  1 file changed, 17 insertions(+), 14 deletions(-)
> 
> diff -puN 
> drivers/ata/pata_pcmcia.c~pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards
>  drivers/ata/pata_pcmcia.c
[cut]

Nope, that did not change anything.  It still detects as PIO0 and still
runs at 1.6 MB/s.
-- 
Zan Lynx <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: git guidance

[Al Boldi]

[EMAIL PROTECTED] wrote:
> On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
> > Because WORKFLOW C is transparent, it won't affect other workflows.  So
> > you could still use your normal WORKFLOW B in addition to WORKFLOW C,
> > gaining an additional level of version control detail at no extra cost
> > other than the git-engine scratch repository overhead.
> >
> > BTW, is git efficient enough to handle WORKFLOW C?
>
> Imagine the number of commits a 'make clean; make' will do in a kernel
> tree, as it commits all those .o files... :)

.o files???

It probably goes without saying, that gitfs should have some basic 
configuration file to setup its transparent behaviour, and which would most 
probably contain an include / exclude file-filter mask, and probably other 
basic configuration options.  But this is really secondary to the 
implementation, and the question remains whether git is efficient enough.

IOW, how big is the git commit overhead as compared to a normal copy?


Thanks!

--
Al

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

Re: x86_64 dynticks not working prev: cpuidle, dynticks compatible or no?

[Ed Sweetman]

Robert Hancock wrote:

Ed Sweetman wrote:
System is idle now, previously it was doing something i couldn't halt 
at the time.  I'm looking at "Local timer interrupts" in the "Loc:" 
section of /proc/interrupts.
Across 1 second while the system is pretty much idle, i still get 300 
interrupts. My HZ variable is set to 300 in the kernel config, so 
this is expected but I was under the assumption that 
dynticks/tickless being compiled in would cause that to be much lower.


Am I reading the wrong section of /proc/interrupts  to verify if 
dynticks is working or not? Again, i see no difference in cpu temp at 
all.


Try running powertop ( http://www.lesswatts.org/projects/powertop/ ) 
and see what it reports.


I don't think dynticks will generally save huge amounts of power on a 
typical desktop machine. The big gains come from being able to stay in 
deep sleep C-states (C2/C3) for longer periods of time, but most 
desktop machines only enable sleep states down to C1.


I tried running powertop, it complains about not having timer 
statistics, I looked throughout the kernel config for a timer stat 
option, but can't find one.


I didn't have hpet compiled in, i'm not sure if this is required but a 
lot of places seem to suggest hpet and high precision timer and tickless 
be compiled together.  I also disabled cpuidle and i'll reboot and try 
that.






In case it helps, this is an athlon64 x2 with apic functioning and 
both cores active in 64bit mode. dmesg is below.

not related :
Some additional notes:  it87 is my lm_sensor, it doesn't work in this 
kernel, yet it did in 2.6.22.  Perhaps enabling high precision timers 
changed something in acpi land.


I enabled tcp dma offloading in this kernel, i get debugging output 
related to it, error is at the last line.  No corruption or otherwise 
bad behavior.   Transferring via cifs at 9.7MB/sec "incoming" took 
about 15% of one cpu...  I never bothered to check if that is the 
norm but i suspect i'll be removing that feature as it seems to not 
play nice with the kernel.




--
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: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

[Bob Tracy]

Kay Sievers wrote:
> Is the udev daemon (still) running while it fails?

Yes.

> If you run /sbin/udevtrigger, do the nodes appear?

No.  Exit status is 0, and there are no errors.  Everything looks
fine under /sys/block, and there doesn't seem to be a problem with
/proc/devices either.

-- 

Bob Tracy  |  "They couldn't hit an elephant at this dist- "
[EMAIL PROTECTED]   |   - Last words of Union General John Sedgwick,
   |  Battle of Spotsylvania Court House, U.S. Civil War

--
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.24-rc4-mm1 and Very Slow PCMCIA Compact Flash

[Robert Hancock]

Zan Lynx wrote:

On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote:

On Fri, 07 Dec 2007 23:09:43 +
Zan Lynx <[EMAIL PROTECTED]> wrote:


On Fri, 2007-12-07 at 15:02 -0800, Andrew Morton wrote:

On Fri, 07 Dec 2007 20:38:24 +
Zan Lynx <[EMAIL PROTECTED]> wrote:


While I'm reporting problems I'll get this one out there.

I normally use a USB-2 memory card reader but I also have a PCMCIA
CompactFlash adapter that I use occasionally.  During the MM series
kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all.  I
don't know about vanilla since I don't run that.

Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I
only get read rates of 1.6 MB/s.  When it used to work in 2.6.20 I got
at least 16 MB/s.  The card itself is capable of 30+ in the USB-2
reader.


[cut]

Oh, OK.  Hopefully the ata guys can help out with this.

I don't know if it actually strictly a regression?  Did libata ever support
that device in any earlier kernels?


That could be why it didn't work for a few kernel versions.  I
reconfigured for a libata-only system a while back.  And, since I
usually use the USB-2 flash reader I didn't care much about the PCMCIA.

I will try reverting that patch later tonight, in a few hours.


It looks like pata_pcmcia is always PIO mode 0:

/**
 *  pcmcia_init_one -   attach a PCMCIA interface
 *  @pdev: pcmcia device
 *
 *  Register a PCMCIA IDE interface. Such interfaces are PIO 0 and
 *  shared IRQ.
 */

I assume that with old IDE this would use ide_cs.c, but I'm drawing a 
blank on what modes that supports..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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/

Re: [PATCH] Fake NUMA emulation for PowerPC

[David Rientjes]

On Sat, 8 Dec 2007, Balbir Singh wrote:

> > You're going to want to distribute the cpu's based on how they match up 
> > physically with the actual platform that you're running on.  x86_64 does 
> 
> Could you explain this better, how does it match up CPU's with fake NUMA
> memory? Is there some smartness there? I'll try and look at the code and
> also see what I can do for PowerPC
> 

numa_cpumask_lookup_table[] would return the correct cpumask for the fake 
node index.  Then all the code that uses node_to_cpumask() in generic 
kernel code like the scheduler and VM still preserve their true NUMA 
affinity that matches the underlying hardware.  I tried to make x86_64 
fake NUMA as close to the real thing as possible.

You also probably want to make all you changes dependent on 
CONFIG_NUMA_EMU like the x86_64 case.  That'll probably be helpful as you 
extend this tool more and more.

David
--
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.24-rc3-git4 NFS crossmnt regression

[Eric W. Biederman]

Alexey Dobriyan <[EMAIL PROTECTED]> writes:

> I very much agree. ->shadow_proc is so ugly, so it's not funny anymore.
> Adding such hook for proc part of networking _and_ for modules is just asking
> for trouble as was demonstrated.

Alexey however we do this we fundamentally have to proc_lookup, if
we don't want weird artifacts showing up in user space.

To me the implementation details don't much matter, as long as we
somehow get proc_lookup to do the right thing.

Eric
--
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] Fake NUMA emulation for PowerPC

[Balbir Singh]

David Rientjes wrote:
> On Sat, 8 Dec 2007, Balbir Singh wrote:
> 
>> Yes, they all appear on node 0. We could have tweaks to distribute CPU's
>> as well.
>>
> 
> You're going to want to distribute the cpu's based on how they match up 
> physically with the actual platform that you're running on.  x86_64 does 

Could you explain this better, how does it match up CPU's with fake NUMA
memory? Is there some smartness there? I'll try and look at the code and
also see what I can do for PowerPC

> this already and it makes fake NUMA more useful because it matches the 
> real-life case more often.

Yes, I agree, but I don't want that to be the first step for fake NUMA
nodes on PowerPC. I think we can incrementally add features.

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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.24-rc4] proc: Remove/Fix proc generic d_revalidate

[Eric W. Biederman]

Ultimately to implement /proc perfectly we need an implementation
of d_revalidate because files and directories can be removed behind
the back of the VFS, and d_revalidate is the only way we can let
the VFS know that this has happened.

Unfortunately the linux VFS can not cope with anything in the path
to a mount point going away.  So a proper d_revalidate method that
calls d_drop also needs to call have_submounts which is moderately
expensive, so you really don't want a d_revalidate method that
unconditionally calls it, but instead only calls it when the
backing object has really gone away.

proc generic entries only disappear on module_unload (when
not counting the fledgling network namespace) so it is quite rare
that we actually encounter that case and has not actually caused
us real world trouble yet.

So until we get a proper test for keeping dentries in the dcache
fix the current d_revalidate method by completely removing it.  This
returns us to the current status quo.

So with CONFIG_NETNS=n things should look as they have always looked.

For CONFIG_NETNS=y things work most of the time but there are a few
rare corner cases that don't behave properly.  As the network namespace
is barely present in 2.6.24 this should not be a problem.

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
 fs/proc/generic.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 8d49838..6a2fe51 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -374,16 +374,9 @@ static int proc_delete_dentry(struct dentry * dentry)
return 1;
 }
 
-static int proc_revalidate_dentry(struct dentry *dentry, struct nameidata *nd)
-{
-   d_drop(dentry);
-   return 0;
-}
-
 static struct dentry_operations proc_dentry_operations =
 {
.d_delete   = proc_delete_dentry,
-   .d_revalidate   = proc_revalidate_dentry,
 };
 
 /*
-- 
1.5.3.rc6.17.g1911

--
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] Fake NUMA emulation for PowerPC

[Balbir Singh]

David Rientjes wrote:
> On Sat, 8 Dec 2007, Balbir Singh wrote:
> 
>> To be able to test the memory controller under NUMA, I use fake NUMA
>> nodes. x86-64 has a similar feature, the code I have here is the
>> simplest I could come up with for PowerPC.
>>
> 
> Magnus Damm had patches from over a year ago that, I believe, made much of 
> the x86_64 fake NUMA code generic so that it could be extended for 
> architectures such as i386.  Perhaps he could resurrect those patches if 
> there is wider interest in such a tool.

That would be a very interesting patch, but what I have here is the
simplest patch and we could build on it incrementally. The interface is
non-standard but it does amazing things for 59 lines of code change.


-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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.24-rc3-git4 NFS crossmnt regression

[Eric W. Biederman]

Andrew Morton <[EMAIL PROTECTED]> writes:

> OK, perhaps a revert is the best thing to do here.  I don't think anyone
> will be expecting fully finalised and robust netns support in 2.6.24.

I do think we expect /proc/net when the netns support is disabled
to be as robust as it has been prior to 2.6.24, which is where we came
in.

The problem I tried to close one hole too many with my previous patch.

The simplest thing to do and that will make things work for everyone
in a tried and true fashion is not a complete revert but to simply
remove d_revalidate (which is causing all of the trouble).

We can figure out how to deal with the VFS mount handling not being
friendly to network filesystems  later.  The implementation details of
VFS mount handling do not lest us remove dcache entries for
directories (even when they have been removed from the backing store)
until we have removed all mounts from them and their children.  Since
I violated that rule. Kaboom!

Eric
--
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.24-rc4-mm1 and /proc//status Name: field

[Eric W. Biederman]

Andrew Morton <[EMAIL PROTECTED]> writes:

> On Fri, 07 Dec 2007 20:26:43 +
> Zan Lynx <[EMAIL PROTECTED]> wrote:
>
>> Today I noticed pgrep doesn't work.  It seems the reason is a missing
>> Name: tag in the status file for a process in /proc.
>> 
>> # cat /proc/1/status
>> init
>> State:  S (sleeping)
>> Tgid:   1
>> Pid:1
>> PPid:   0
>> TracerPid:  0
>> ...etc, etc...
>> 
>> This is supposed to look like:
>> # cat /proc/1/status
>> Name:init
>> State:   S (sleeping)
>> Tgid:1
>> Pid: 1
>> PPid:0
>> TracerPid:   0
>> ...
>> 
>
> Thanks.  Two (more) bugs in
> proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces.patch

Doh!  How did I get that one confused?

Thanks.
Eric


>
> ---
> a/fs/proc/array.c~proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-fix-3
> +++ a/fs/proc/array.c
> @@ -98,9 +98,9 @@ static inline void task_name(struct seq_
>  
>   get_task_comm(tcomm, p);
>  
> + seq_printf(m, "Name:\t");
>   end = m->buf + m->size;
>   buf = m->buf + m->count;
> - seq_printf(m, "Name:\n");
>   name = tcomm;
>   i = sizeof(tcomm);
>   while (i && (buf < end)) {
> _
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86_64 dynticks not working prev: cpuidle, dynticks compatible or no?

[Robert Hancock]

Ed Sweetman wrote:
System is idle now, previously it was doing something i couldn't halt at 
the time.  I'm looking at "Local timer interrupts" in the "Loc:" section 
of /proc/interrupts.
Across 1 second while the system is pretty much idle, i still get 300 
interrupts. My HZ variable is set to 300 in the kernel config, so this 
is expected but I was under the assumption that dynticks/tickless being 
compiled in would cause that to be much lower.


Am I reading the wrong section of /proc/interrupts  to verify if 
dynticks is working or not? Again, i see no difference in cpu temp at all.


Try running powertop ( http://www.lesswatts.org/projects/powertop/ ) and 
see what it reports.


I don't think dynticks will generally save huge amounts of power on a 
typical desktop machine. The big gains come from being able to stay in 
deep sleep C-states (C2/C3) for longer periods of time, but most desktop 
machines only enable sleep states down to C1.




In case it helps, this is an athlon64 x2 with apic functioning and both 
cores active in 64bit mode. dmesg is below.

not related :
Some additional notes:  it87 is my lm_sensor, it doesn't work in this 
kernel, yet it did in 2.6.22.  Perhaps enabling high precision timers 
changed something in acpi land.


I enabled tcp dma offloading in this kernel, i get debugging output 
related to it, error is at the last line.  No corruption or otherwise 
bad behavior.   Transferring via cifs at 9.7MB/sec "incoming" took about 
15% of one cpu...  I never bothered to check if that is the norm but i 
suspect i'll be removing that feature as it seems to not play nice with 
the kernel.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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/

oops with 2.6.23.1, marvel, software raid, reiserfs and samba

[jeffunit]

I am running linux kernel 2.6.23.1, which I compiled.
The base system was mandriva 2008.

I have a dual processor pentium III 933 system.
It has 3gb of ram, an intel stl-2 motherboard.
It also has a promise 100 tx2 pata controller,
a supermicro marvell based 8 port pcix sata controller,
and a nvidia pci based video card.

I have the os on a pata drive, and have made a software raid array
consisting of 4 sata drives attached to the pcix sata controller.
I created the array, and formatted with reiserfs 3.6
I have run bonnie++ (filesystem benchmark) on the array without incident.
When I use samba-3.0.25b-4.3 and copy files from a windows machine to 
the fileserver,

every so often, the fileserver crashes or hangs. It seems to happen
more often under heavy samba traffic.
Enclosed is the oops from syslog.
I also have a 'kernel bug' from syslog if that would be helpful.

jeff


Dec  7 17:20:52 sata_fileserver kernel: BUG: unable to handle kernel 
NULL pointer dereference at virtual address 000d

Dec  7 17:20:52 sata_fileserver kernel:  printing eip:
Dec  7 17:20:52 sata_fileserver kernel: c02cc820
Dec  7 17:20:52 sata_fileserver kernel: *pde = 
Dec  7 17:20:52 sata_fileserver kernel: Oops:  [#1]
Dec  7 17:20:52 sata_fileserver kernel: SMP
Dec  7 17:20:52 sata_fileserver kernel: Modules linked in: raid456 
async_xor async_memcpy async_tx xor iptable_raw xt_comment xt_policy 
xt_multiport ipt_ULOG ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_SAME 
ipt_REJECT ipt_REDIRECT ipt_recent ipt_owner ipt_NETMAP 
ipt_MASQUERADE ipt_LOG ipt_iprange ipt_ECN ipt_ecn ipt_CLUSTERIP 
ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip 
nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp 
nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_tftp 
nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp 
nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns 
nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss 
xt_pkttype xt_physdev xt_NFQUEUE xt_NFLOG xt_MARK xt_mark xt_mac 
xt_limit xt_length xt_helper xt_hashlimit ip6_tables xt_dccp 
xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY nfsd xt_tcpudp 
exportfs auth_rpcgss xt_state iptable_nat nf_nat nf_conntrack_ipv4 
nf_conntrack nfs iptable_mangle lockd nfs_acl sunrpc nfnetlink 
iptable_filter ip_table
Dec  7 17:20:52 sata_fileserver kernel:  x_tables af_packet ipv6 
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss 
snd_mixer_oss ipmi_si ipmi_msghandler binfmt_misc loop nls_utf8 ntfs 
dm_mod usb_storage sg sd_mod sata_mv libata scsi_mod video output 
thermal sbs processor fan container button dock battery ac floppy 
snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm 
snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep 
ehci_hcd snd ohci_hcd i2c_piix4 uhci_hcd soundcore e1000 sworks_agp 
i2c_core ide_cd usbcore agpgart emu10k1_gp gameport tsdev evdev 
reiserfs ide_disk serverworks pdc202xx_new ide_core

Dec  7 17:20:52 sata_fileserver kernel: CPU:1
Dec  7 17:20:52 sata_fileserver kernel: 
EIP:0060:[]Not tainted VLI

Dec  7 17:20:52 sata_fileserver kernel: EFLAGS: 00210202   (2.6.23.1 #1)
Dec  7 17:20:52 sata_fileserver kernel: EIP is at tcp_recvmsg+0x150/0xbf0
Dec  7 17:20:52 sata_fileserver kernel: eax:    ebx: 
f55c4b60   ecx: 784e2c7c   edx: f63f63d8
Dec  7 17:20:52 sata_fileserver kernel: esi: 784e2c7a   edi: 
f63f614c   ebp: e21fde24   esp: e21fddc4
Dec  7 17:20:52 sata_fileserver kernel: ds: 007b   es: 007b   fs: 
00d8  gs: 0033  ss: 0068
Dec  7 17:20:52 sata_fileserver kernel: Process smbd (pid: 9524, 
ti=e21fc000 task=f5109000 task.ti=e21fc000)
Dec  7 17:20:52 sata_fileserver kernel: Stack:   
 c13e5740 f557b000 c03fa300  e21fde90
Dec  7 17:20:52 sata_fileserver kernel:f63f60e0  
0b64 f63f63d8 05b4 0001  
Dec  7 17:20:52 sata_fileserver kernel: 05b4 
e21fde4c 7fff e21fde28  c03a4de0 e21fde90

Dec  7 17:20:52 sata_fileserver kernel: Call Trace:
Dec  7 17:20:53 sata_fileserver kernel:  [] 
show_trace_log_lvl+0x1a/0x30
Dec  7 17:20:53 sata_fileserver kernel:  [] 
show_stack_log_lvl+0xab/0xd0
Dec  7 17:20:53 sata_fileserver kernel:  [] 
show_registers+0x1d1/0x2d0

Dec  7 17:20:53 sata_fileserver kernel:  [] die+0x116/0x250
Dec  7 17:20:53 sata_fileserver kernel:  [] do_page_fault+0x28b/0x6a0
Dec  7 17:20:53 sata_fileserver kernel:  [] error_code+0x72/0x78
Dec  7 17:20:53 sata_fileserver kernel:  [] 
sock_common_recvmsg+0x43/0x60

Dec  7 17:20:53 sata_fileserver kernel:  [] sock_aio_read+0x11c/0x130
Dec  7 17:20:53 sata_fileserver kernel:  [] do_sync_read+0xd0/0x110
Dec  7 17:20:53 sata_fileserver kernel:  [] vfs_read+0x12d/0x140
Dec  7 17:20:53 sata_fileserver kernel:  [] sys_read+0x3d/0x70
Dec  7 17:20:53 sata_fileserver kernel:  [] 
sysenter_past_esp+0x6b/0xa1

Dec  7 17:20:53 sata_fileserver kernel:  ===
Dec  7 17:20:53 sata_fileserver kernel: C

Re: Possible EXT2 race

[Robert Hancock]

linux-os (Dick Johnson) wrote:

On Fri, 7 Dec 2007, Dave Jones wrote:


On Fri, Dec 07, 2007 at 08:15:42AM -0500, linux-os (Dick Johnson) wrote:


Dec  7 04:05:55 chaos kernel: sd 0:0:1:0: [sdb] Add. Sense: Peripheral device 
write fault

This sounds more like a hardware problem.

Dave



There was an attempt to write beyond the end of the device because
everything in the file-system was getting trashed. I can read/write
the 5 year-old SCSI physical drive with no errors from both within
linux and through the Adaptec BIOS. This problem only occurs
when I attempt to truncate a file that is being written by another
task.


That SCSI error code doesn't sound like a reasonable one for the drive 
getting a bad block address. The more typical one in that case would be 
"Logical block address out of range", or maybe the catch-all "Invalid 
field in CDB". "Peripheral device write fault", especially as a deferred 
error (i.e. after the drive already returned a normal completion for the 
data, and then is reporting the failure to actually write to the media 
on the next command), really sounds like a drive problem.


And the kernel is supposed to trap those at the disk layer, like these 
are saying it is, _after_ that error occurs:


Dec  7 04:08:13 chaos kernel: attempt to access beyond end of device
Dec  7 04:08:13 chaos kernel: sdb1: rw=0, want=29687515944, limit=33736437

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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/

Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec

[Geoff Levand]

On 12/05/2007 10:09 PM, Yasunori Goto wrote:
>> I'll try Milton's suggestion to pre-allocate the memory early.  It seems
>> that should work as long as nothing else before the hot-plug mem is added
>> needs a large chunk.
> 
> (However, I think Milton-san's suggestion is very desirable. 
>  If preallocation of hotadd works on ia64 too, I'm very glad.)

As it turns out, preallocation is not a such a good solution I
think because in the general case the system may need many
allocations to support the added memory, so it would be difficult
to know how much pre-allocated memory is needed.  I think a
preferable solution is to use memory from the newly added
region.

I don't plan to work on a pre-allocation method.  I think I can
free up sufficient memory in other ways.

-Geoff

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

[PATCH 3/4] mcheck mce_64: mce_read_sem to mutex

[Daniel Walker]

Converted to a mutex, and changed the name to mce_read_mutex.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>


---
 arch/x86/kernel/cpu/mcheck/mce_64.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6.23/arch/x86/kernel/cpu/mcheck/mce_64.c
===
--- linux-2.6.23.orig/arch/x86/kernel/cpu/mcheck/mce_64.c
+++ linux-2.6.23/arch/x86/kernel/cpu/mcheck/mce_64.c
@@ -564,7 +564,7 @@ static ssize_t mce_read(struct file *fil
loff_t *off)
 {
unsigned long *cpu_tsc;
-   static DECLARE_MUTEX(mce_read_sem);
+   static DEFINE_MUTEX(mce_read_mutex);
unsigned next;
char __user *buf = ubuf;
int i, err;
@@ -573,12 +573,12 @@ static ssize_t mce_read(struct file *fil
if (!cpu_tsc)
return -ENOMEM;
 
-   down(&mce_read_sem);
+   mutex_lock(&mce_read_mutex);
next = rcu_dereference(mcelog.next);
 
/* Only supports full reads right now */
if (*off != 0 || usize < MCE_LOG_LEN*sizeof(struct mce)) {
-   up(&mce_read_sem);
+   mutex_unlock(&mce_read_mutex);
kfree(cpu_tsc);
return -EINVAL;
}
@@ -621,7 +621,7 @@ static ssize_t mce_read(struct file *fil
memset(&mcelog.entry[i], 0, sizeof(struct mce));
}
}
-   up(&mce_read_sem);
+   mutex_unlock(&mce_read_mutex);
kfree(cpu_tsc);
return err ? -EFAULT : buf - ubuf;
 }

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

[PATCH 4/4] md: dm driver: suspend_lock semaphore to mutex

[Daniel Walker]

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 drivers/md/dm.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

Index: linux-2.6.23/drivers/md/dm.c
===
--- linux-2.6.23.orig/drivers/md/dm.c
+++ linux-2.6.23/drivers/md/dm.c
@@ -73,7 +73,7 @@ union map_info *dm_get_mapinfo(struct bi
 
 struct mapped_device {
struct rw_semaphore io_lock;
-   struct semaphore suspend_lock;
+   struct mutex suspend_lock;
spinlock_t pushback_lock;
rwlock_t map_lock;
atomic_t holders;
@@ -982,7 +982,7 @@ static struct mapped_device *alloc_dev(i
 
memset(md, 0, sizeof(*md));
init_rwsem(&md->io_lock);
-   init_MUTEX(&md->suspend_lock);
+   mutex_init(&md->suspend_lock);
spin_lock_init(&md->pushback_lock);
rwlock_init(&md->map_lock);
atomic_set(&md->holders, 1);
@@ -1270,7 +1270,7 @@ int dm_swap_table(struct mapped_device *
 {
int r = -EINVAL;
 
-   down(&md->suspend_lock);
+   mutex_lock(&md->suspend_lock);
 
/* device must be suspended */
if (!dm_suspended(md))
@@ -1285,7 +1285,7 @@ int dm_swap_table(struct mapped_device *
r = __bind(md, table);
 
 out:
-   up(&md->suspend_lock);
+   mutex_unlock(&md->suspend_lock);
return r;
 }
 
@@ -1341,7 +1341,7 @@ int dm_suspend(struct mapped_device *md,
int do_lockfs = suspend_flags & DM_SUSPEND_LOCKFS_FLAG ? 1 : 0;
int noflush = suspend_flags & DM_SUSPEND_NOFLUSH_FLAG ? 1 : 0;
 
-   down(&md->suspend_lock);
+   mutex_lock(&md->suspend_lock);
 
if (dm_suspended(md))
goto out_unlock;
@@ -1462,7 +1462,7 @@ out:
dm_table_put(map);
 
 out_unlock:
-   up(&md->suspend_lock);
+   mutex_unlock(&md->suspend_lock);
return r;
 }
 
@@ -1472,7 +1472,7 @@ int dm_resume(struct mapped_device *md)
struct bio *def;
struct dm_table *map = NULL;
 
-   down(&md->suspend_lock);
+   mutex_lock(&md->suspend_lock);
if (!dm_suspended(md))
goto out;
 
@@ -1508,7 +1508,7 @@ int dm_resume(struct mapped_device *md)
 
 out:
dm_table_put(map);
-   up(&md->suspend_lock);
+   mutex_unlock(&md->suspend_lock);
 
return r;
 }

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

[PATCH 1/4] media: video: usbvision: remove ctrlUrbLock

[Daniel Walker]

The ctrlUrbLock has all it's users commented out, and so it's unused.
This patch removes it.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 drivers/media/video/usbvision/usbvision-core.c  |3 ---
 drivers/media/video/usbvision/usbvision-video.c |1 -
 drivers/media/video/usbvision/usbvision.h   |1 -
 3 files changed, 5 deletions(-)

Index: linux-2.6.23/drivers/media/video/usbvision/usbvision-core.c
===
--- linux-2.6.23.orig/drivers/media/video/usbvision/usbvision-core.c
+++ linux-2.6.23/drivers/media/video/usbvision/usbvision-core.c
@@ -1561,13 +1561,10 @@ static int usbvision_write_reg_irq(struc
if (len > 8) {
return -EFAULT;
}
-// down(&usbvision->ctrlUrbLock);
if (usbvision->ctrlUrbBusy) {
-// up(&usbvision->ctrlUrbLock);
return -EBUSY;
}
usbvision->ctrlUrbBusy = 1;
-// up(&usbvision->ctrlUrbLock);
 
usbvision->ctrlUrbSetup.bRequestType = USB_DIR_OUT | USB_TYPE_VENDOR | 
USB_RECIP_ENDPOINT;
usbvision->ctrlUrbSetup.bRequest = USBVISION_OP_CODE;
Index: linux-2.6.23/drivers/media/video/usbvision/usbvision-video.c
===
--- linux-2.6.23.orig/drivers/media/video/usbvision/usbvision-video.c
+++ linux-2.6.23/drivers/media/video/usbvision/usbvision-video.c
@@ -1650,7 +1650,6 @@ static struct usb_usbvision *usbvision_a
goto err_exit;
}
init_waitqueue_head(&usbvision->ctrlUrb_wq);
-   init_MUTEX(&usbvision->ctrlUrbLock);/* to 1 == available */
 
usbvision_init_powerOffTimer(usbvision);
 
Index: linux-2.6.23/drivers/media/video/usbvision/usbvision.h
===
--- linux-2.6.23.orig/drivers/media/video/usbvision/usbvision.h
+++ linux-2.6.23/drivers/media/video/usbvision/usbvision.h
@@ -374,7 +374,6 @@ struct usb_usbvision {
int ctrlUrbBusy;
struct usb_ctrlrequest ctrlUrbSetup;
wait_queue_head_t ctrlUrb_wq;   // 
Processes waiting
-   struct semaphore ctrlUrbLock;
 
/* configuration part */
int have_tuner;

-- 
--
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/4] docs: kernel-locking: Convert semaphore references

[Daniel Walker]

I converted some of the document to reflect mutex usage instead of
semaphore usage. Since we shouldin't be promoting semaphore usage when
it's on it's way out..

Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>

---
 Documentation/DocBook/kernel-locking.tmpl |   32 +++---
 1 file changed, 16 insertions(+), 16 deletions(-)

Index: linux-2.6.23/Documentation/DocBook/kernel-locking.tmpl
===
--- linux-2.6.23.orig/Documentation/DocBook/kernel-locking.tmpl
+++ linux-2.6.23/Documentation/DocBook/kernel-locking.tmpl
@@ -717,7 +717,7 @@ used, and when it gets full, throws out 
 
 For our first example, we assume that all operations are in user
 context (ie. from system calls), so we can sleep.  This means we can
-use a semaphore to protect the cache and all the objects within
+use a mutex to protect the cache and all the objects within
 it.  Here's the code:
 
 
@@ -725,7 +725,7 @@ it.  Here's the code:
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 struct object
@@ -737,7 +737,7 @@ struct object
 };
 
 /* Protects the cache, cache_num, and the objects within it */
-static DECLARE_MUTEX(cache_lock);
+static DEFINE_MUTEX(cache_lock);
 static LIST_HEAD(cache);
 static unsigned int cache_num = 0;
 #define MAX_CACHE_SIZE 10
@@ -789,17 +789,17 @@ int cache_add(int id, const char *name)
 obj->id = id;
 obj->popularity = 0;
 
-down(&cache_lock);
+mutex_lock(&cache_lock);
 __cache_add(obj);
-up(&cache_lock);
+mutex_unlock(&cache_lock);
 return 0;
 }
 
 void cache_delete(int id)
 {
-down(&cache_lock);
+mutex_lock(&cache_lock);
 __cache_delete(__cache_find(id));
-up(&cache_lock);
+mutex_unlock(&cache_lock);
 }
 
 int cache_find(int id, char *name)
@@ -807,13 +807,13 @@ int cache_find(int id, char *name)
 struct object *obj;
 int ret = -ENOENT;
 
-down(&cache_lock);
+mutex_lock(&cache_lock);
 obj = __cache_find(id);
 if (obj) {
 ret = 0;
 strcpy(name, obj->name);
 }
-up(&cache_lock);
+mutex_unlock(&cache_lock);
 return ret;
 }
 
@@ -853,7 +853,7 @@ The change is shown below, in standard p
  int popularity;
  };
 
--static DECLARE_MUTEX(cache_lock);
+-static DEFINE_MUTEX(cache_lock);
 +static spinlock_t cache_lock = SPIN_LOCK_UNLOCKED;
  static LIST_HEAD(cache);
  static unsigned int cache_num = 0;
@@ -870,22 +870,22 @@ The change is shown below, in standard p
  obj->id = id;
  obj->popularity = 0;
 
--down(&cache_lock);
+-mutex_lock(&cache_lock);
 +spin_lock_irqsave(&cache_lock, flags);
  __cache_add(obj);
--up(&cache_lock);
+-mutex_unlock(&cache_lock);
 +spin_unlock_irqrestore(&cache_lock, flags);
  return 0;
  }
 
  void cache_delete(int id)
  {
--down(&cache_lock);
+-mutex_lock(&cache_lock);
 +unsigned long flags;
 +
 +spin_lock_irqsave(&cache_lock, flags);
  __cache_delete(__cache_find(id));
--up(&cache_lock);
+-mutex_unlock(&cache_lock);
 +spin_unlock_irqrestore(&cache_lock, flags);
  }
 
@@ -895,14 +895,14 @@ The change is shown below, in standard p
  int ret = -ENOENT;
 +unsigned long flags;
 
--down(&cache_lock);
+-mutex_lock(&cache_lock);
 +spin_lock_irqsave(&cache_lock, flags);
  obj = __cache_find(id);
  if (obj) {
  ret = 0;
  strcpy(name, obj->name);
  }
--up(&cache_lock);
+-mutex_unlock(&cache_lock);
 +spin_unlock_irqrestore(&cache_lock, flags);
  return ret;
  }

-- 
--
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: soft lockup - CPU#1 stuck for 15s! [swapper:0]

[Thomas Gleixner]

On Fri, 7 Dec 2007, Pallipadi, Venkatesh wrote:
> >-Original Message-
> >From: Parag Warudkar [mailto:[EMAIL PROTECTED] 
> >Sent: Friday, December 07, 2007 2:54 PM
> >To: LKML
> >Cc: Andrew Morton; Pallipadi, Venkatesh; Linus Torvalds
> >Subject: BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
> >
> >Got this on today's git (2.6.24-rc4) while compiling  stuff - Looks
> >like it is related to CpuIdle stuff.
> >I chose CONFIG_CPU_IDLE for the first time so I don't know when this
> >was introduced.
> >
> >This is on x86_32, SMP.
> >
> >BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
> >
> >Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3)
> >EIP: 0060:[] EFLAGS: 0202 CPU: 1
> >EIP is at _spin_lock_irqsave+0x16/0x27
> >EAX: c06b4110 EBX: 0001 ECX: f7873808 EDX: 0293
> >ESI: 0005 EDI: f7873808 EBP:  ESP: f7829f10
> > DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
> >CR0: 8005003b CR2: 004f5960 CR3: 372c5000 CR4: 06d0
> >DR0:  DR1:  DR2:  DR3: 
> >DR6: 0ff0 DR7: 0400
> > [] tick_broadcast_oneshot_control+0x10/0xda
> > [] tick_notify+0x1d4/0x2eb
> > [] get_next_timer_interrupt+0x143/0x1b4
> > [] notifier_call_chain+0x2a/0x47
> > [] raw_notifier_call_chain+0x17/0x1a
> > [] clockevents_notify+0x19/0x4f
> > [] acpi_idle_enter_simple+0x183/0x1d0
> > [] cpuidle_idle_call+0x53/0x78
> > [] cpuidle_idle_call+0x0/0x78
> > [] cpu_idle+0x97/0xb8
> >
> 
> Looks like tick_broadcast_lock did not get freed in some path.
> You do not see this when you CPU_IDLE is not configured? 

This looks pretty much like the problem I was solving yesterday.

Parag, can you please try Linus latest and please check whether there
is a stack trace with clockevents_program_event on the top in your
dmesg.

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

Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec

[Geoff Levand]

Yasunori Goto wrote:
>> On Thu, 6 Dec 2007, Geert Uytterhoeven wrote:
>> > On Thu, 6 Dec 2007, Yasunori Goto wrote:
>> > > > I'll try Milton's suggestion to pre-allocate the memory early.  It 
>> > > > seems
>> > > > that should work as long as nothing else before the hot-plug mem is 
>> > > > added
>> > > > needs a large chunk.
>> > > 
>> > > Hello. Geoff-san. Sorry for late response.
>> > > 
>> > > Could you tell me the value of the following page_size calculation
>> > > in vmemmap_populate()? I think this page_size may be too big value. 
>> > > 
>> > > --
>> > > int __meminit vmemmap_populate(struct page *start_page,
>> > >unsigned long nr_pages, int node)
>> > >:
>> > >:
>> > > unsigned long page_size = 1 << 
>> > > mmu_psize_defs[mmu_linear_psize].shift;
>> > >:
>> > > ---
>> 
>> 16 MiB of course.
> 
> 16 MiB is not page size. It is "section size". 
> IIRC, powerpc's page size must be 4K (or 64K).
> If page size is 4k, vmemmap_alloc_block will call the order 12 page.


By default PS3 uses 4K virtual pages, and 16M linear pages.


> Is it really correct value for vmemmap population?


It seems vmemmap needs linear pages, so I think it is ok.


>> PS3 initially starts with 128 MiB.
>> Later hotplug is used to add the remaining memory (96 or 112 MIB, IIRC).
> 
> Ok.
> Then, add_memory() must be called 6 or 7 times for each sections.


Yes, I call add_memory() once, then it in turn calls sparse_add_one_section()
7 times.

-Geoff


--
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.24-rc4-git5: Reported regressions from 2.6.23

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.23 which have been
reported since 2.6.24-rc1 was released and for which there are no fixes in the
mainline that I know of.  If any of them have been fixed already, please let me
know.

If you know of any other unresolved regressions from 2.6.23, please let me know
either and I'll add them to the list.


Subject : EHCI causes system to resume instantly from S4
Submitter   : Maxim Levitsky <[EMAIL PROTECTED]>
References  : http://lkml.org/lkml/2007/10/27/66
  http://bugzilla.kernel.org/show_bug.cgi?id=9258
Handled-By  : "Rafael J. Wysocki" <[EMAIL PROTECTED]>
  David Brownell <[EMAIL PROTECTED]>
  Alan Stern <[EMAIL PROTECTED]>
Patch   : 
Note:   : the problem appears to heavily depend on hardware


Subject : leds: ledtrig-timer calls sleeping function from invalid 
context
Submitter   : Márton Németh <[EMAIL PROTECTED]>
References  : http://bugzilla.kernel.org/show_bug.cgi?id=9264
Handled-By  : Richard Purdie <[EMAIL PROTECTED]>
Patch   : http://bugzilla.kernel.org/attachment.cgi?id=13493&action=view


Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond 
end of object
Submitter   : Hans de Bruin <[EMAIL PROTECTED]>
References  : http://bugzilla.kernel.org/show_bug.cgi?id=9320
Handled-By  : Robert Moore <[EMAIL PROTECTED]>
  Tejun Heo <[EMAIL PROTECTED]>
  Fu Michael <[EMAIL PROTECTED]>
Patch   : 


Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always work on 
Lenovo X60s
Submitter   : Roland Dreier <[EMAIL PROTECTED]>
References  : http://lkml.org/lkml/2007/11/8/255
  http://bugzilla.kernel.org/show_bug.cgi?id=9332
Handled-By  : 
Patch   : 


Subject : system hangs after a few minutes
Submitter   : Marcus Better <[EMAIL PROTECTED]>
References  : http://bugzilla.kernel.org/show_bug.cgi?id=9335
Handled-By  : Andrew Morton <[EMAIL PROTECTED]>
  Alan Stern <[EMAIL PROTECTED]>
Patch   : http://bugzilla.kernel.org/attachment.cgi?id=13871&action=view


Subject : cd/dvd inaccessible in 2.6.24-rc2
Submitter   : Will Trives <[EMAIL PROTECTED]>
References  : http://lkml.org/lkml/2007/11/9/290
  http://bugzilla.kernel.org/show_bug.cgi?id=9346
Handled-By  : Len Brown <[EMAIL PROTECTED]>
  Tejun Heo <[EMAIL PROTECTED]>
Patch   : 


Subject : The keyboard doesn't work
Submitter   : Francois Valenduc <[EMAIL PROTECTED]>
References  : http://bugzilla.kernel.org/show_bug.cgi?id=9362
Handled-By  : Dmitry Torokhov <[EMAIL PROTECTED]>
  Ingo Molnar <[EMAIL PROTECTED]>
  Alexey Starikovskiy <[EMAIL PROTECTED]>
Patch   : http://bugzilla.kernel.org/attachment.cgi?id=13892&action=view
  http://bugzilla.kernel.org/attachment.cgi?id=13893&action=view
  http://bugzilla.kernel.org/attachment.cgi?id=13907&action=view
Note: patches to apply in this order, top-down


Subject : v2.6.24-rc2-409-g9418d5d: attempt to access beyond end of 
device
Submitter   : Thomas Meyer <[EMAIL PROTECTED]>
References  : http://lkml.org/lkml/2007/11/13/250
  http://bugzilla.kernel.org/show_bug.cgi?id=9370
Handled-By  : Matthew Wilcox <[EMAIL PROTECTED]>
Patch   : 


Subject : SError: { DevExch } occuring and causing disruption
Submitter   : Avuton Olrich <[EMAIL PROTECTED]>
References  : http://bugzilla.kernel.org/show_bug.cgi?id=9393
Handled-By  : Tejun Heo <[EMAIL PROTECTED]>
  Mark Lord <[EMAIL PROTECTED]>
Patch   : 


Subject : nfsd gets stuck when underlying filesystem is XFS
Submitter   : Christian Kujau <[EMAIL PROTECTED]>
  Chris Wedgwood <[EMAIL PROTECTED]>
References  : http://bugzilla.kernel.org/show_bug.cgi?id=9400
Handled-By  : "J. Bruce Fields" <[EMAIL PROTECTED]>
  Christoph Hellwig <[EMAIL PROTECTED]>
Patch   : http://lkml.org/lkml/2007/11/25/39


Subject : 2.6.24-rc3: find complains about /proc/net
Submitter   : Pavel Machek <[EMAIL PROTECTED]>
References  : http://lkml.org/lkml/2007/11/19/253
  http://bugzilla.kernel.org/show_bug.cgi?id=9411
Handled-By  : "Eric W. Biederman" <[EMAIL PROTECTED]>
Patch   :
Note: the existing fix needs fixing


Subject : Not work light of button-led with module b43 in chipset 
broadcom 4318
Submitter   : Cristian Aravena Romero <[EMAIL PROTECTED]>
References  : http://bugzilla.kernel.org/show_bug.cgi?id=9414
Handled-By  : 
Patch   : 


Subject : unable to turn cooling device 'off' - LG LE50 Express laptop
Submitter   : Marcus Better <[EMAIL PROTECTED]>
References  :

Re: BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]

[Rafael J. Wysocki]

On Saturday, 8 of December 2007, Andrew Morton wrote:
> On Fri, 7 Dec 2007 17:53:47 -0500
> "Parag Warudkar" <[EMAIL PROTECTED]> wrote:
> 
> > Got this on today's git (2.6.24-rc4) while compiling  stuff - Looks
> > like it is related to CpuIdle stuff.
> > I chose CONFIG_CPU_IDLE for the first time so I don't know when this
> > was introduced.
> > 
> > This is on x86_32, SMP.
> > 
> > BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
> > 
> > Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3)
> > EIP: 0060:[] EFLAGS: 0202 CPU: 1
> > EIP is at _spin_lock_irqsave+0x16/0x27
> > EAX: c06b4110 EBX: 0001 ECX: f7873808 EDX: 0293
> > ESI: 0005 EDI: f7873808 EBP:  ESP: f7829f10
> >  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
> > CR0: 8005003b CR2: 004f5960 CR3: 372c5000 CR4: 06d0
> > DR0:  DR1:  DR2:  DR3: 
> > DR6: 0ff0 DR7: 0400
> >  [] tick_broadcast_oneshot_control+0x10/0xda
> >  [] tick_notify+0x1d4/0x2eb
> >  [] get_next_timer_interrupt+0x143/0x1b4
> >  [] notifier_call_chain+0x2a/0x47
> >  [] raw_notifier_call_chain+0x17/0x1a
> >  [] clockevents_notify+0x19/0x4f
> >  [] acpi_idle_enter_simple+0x183/0x1d0
> >  [] cpuidle_idle_call+0x53/0x78
> >  [] cpuidle_idle_call+0x0/0x78
> >  [] cpu_idle+0x97/0xb8
> 
> OK, thanks.  Another one for the regression list, please.

Added, http://bugzilla.kernel.org/show_bug.cgi?id=9525, thanks.
--
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.24-rc3-git4 NFS crossmnt regression

[Shane]

On Dec 7, 2007 7:15 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Sat, 8 Dec 2007 03:00:43 +0300
> Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Dec 08, 2007 at 12:43:28AM +0100, Rafael J. Wysocki wrote:
> > > On Saturday, 8 of December 2007, Andrew Morton wrote:
> > > > On Fri, 07 Dec 2007 17:51:58 -0500
> > > > Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >
> > > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > > > On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote:
> > > > > > ...
> > > > > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few 
> > > > > > > more
> > > > > > > spots and check for other regressions.
> > > > > >
> > > > > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > > > > server. And now I don't see anything at all in the crossmnt dirs.
> > > > > >
> > > > > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > > > >
> > > > > > Are there any other pending fixes?
> > > > > >
> > > > > > Shane
> > > > >
> > > > > You've probably fallen afoul of
> > > > >
> > > > >http://bugzilla.kernel.org/show_bug.cgi?id=9504
> > > > >
> > > >
> > > > Yeah.
> > > >
> > > > I have a tentative fix below but I can't seem to get Eric and Denis to 
> > > > get
> > > > a suitable fix nailed down.  It's urgent!
> > >
> > > Well, how about asking Linus to revert commit
> > > 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over 
> > > again?
> > >
> > > It apparently causes more trouble than the issue it was supposed to fix.
> >
> > I very much agree. ->shadow_proc is so ugly, so it's not funny anymore.
> > Adding such hook for proc part of networking _and_ for modules is just 
> > asking
> > for trouble as was demonstrated.
>
> OK, perhaps a revert is the best thing to do here.  I don't think anyone
> will be expecting fully finalised and robust netns support in 2.6.24.

I reverted 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 and it does fix the NFS
server problem with crossmnt's for me.

Shane
--
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: AF_IPN: Inter Process Networking, try these...

[David Miller]

From: [EMAIL PROTECTED] (Renzo Davoli)
Date: Fri, 7 Dec 2007 22:18:05 +0100

> I disagree. If you suspect we would be better using IP multicast, I think
> your suspects are not supported.
> Try the following exercises, please Can you provide better solutions
> without IPN?

I personally have not purely advocated IP, although the performance
differences UDP and AF_UNIX should be investigated.

Instead I advocated using AF_NETLINK with some minor multicast
permission modifications to suit your needs.
--
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] ecryptfs: make show_options reflect actual mount options

[Eric Sandeen]

Change ecryptfs_show_options to reflect the actual mount
options in use.  Note that this does away with the "dir="
output, which is not a valid mount option and appears to be
unused.

Mount options such as "ecryptfs_verbose" and
"ecryptfs_xattr_metadata" are somewhat indeterminate for
a given fs, but in any case the reported mount options can
be used in a new mount command to get the same behavior.

Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Acked-by: Michael Halcrow <[EMAIL PROTECTED]>

---

Index: linux/fs/ecryptfs/super.c
===
--- linux.orig/fs/ecryptfs/super.c
+++ linux/fs/ecryptfs/super.c
@@ -157,32 +157,42 @@ static void ecryptfs_clear_inode(struct 
 /**
  * ecryptfs_show_options
  *
- * Prints the directory we are currently mounted over.
- * Returns zero on success; non-zero otherwise
+ * Prints the mount options for a given superblock.
+ * Returns zero; does not fail.
  */
 static int ecryptfs_show_options(struct seq_file *m, struct vfsmount *mnt)
 {
struct super_block *sb = mnt->mnt_sb;
-   struct dentry *lower_root_dentry = ecryptfs_dentry_to_lower(sb->s_root);
-   struct vfsmount *lower_mnt = ecryptfs_dentry_to_lower_mnt(sb->s_root);
-   char *tmp_page;
-   char *path;
-   int rc = 0;
-
-   tmp_page = (char *)__get_free_page(GFP_KERNEL);
-   if (!tmp_page) {
-   rc = -ENOMEM;
-   goto out;
-   }
-   path = d_path(lower_root_dentry, lower_mnt, tmp_page, PAGE_SIZE);
-   if (IS_ERR(path)) {
-   rc = PTR_ERR(path);
-   goto out;
+   struct ecryptfs_mount_crypt_stat *mount_crypt_stat =
+   &ecryptfs_superblock_to_private(sb)->mount_crypt_stat;
+   struct ecryptfs_global_auth_tok *walker;
+
+   mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex);
+   list_for_each_entry(walker,
+   &mount_crypt_stat->global_auth_tok_list,
+   mount_crypt_stat_list) {
+   seq_printf(m, ",ecryptfs_sig=%s", walker->sig);
}
-   seq_printf(m, ",dir=%s", path);
-   free_page((unsigned long)tmp_page);
-out:
-   return rc;
+   mutex_unlock(&mount_crypt_stat->global_auth_tok_list_mutex);
+
+   /* Note this is global and probably shouldn't be a mount option */
+   if (ecryptfs_verbosity)
+   seq_printf(m, ",ecryptfs_debug=%d\n", ecryptfs_verbosity);
+
+   seq_printf(m, ",ecryptfs_cipher=%s",
+   mount_crypt_stat->global_default_cipher_name);
+
+   if (mount_crypt_stat->global_default_cipher_key_size)
+   seq_printf(m, ",ecryptfs_key_bytes=%d",
+  mount_crypt_stat->global_default_cipher_key_size);
+   if (mount_crypt_stat->flags & ECRYPTFS_PLAINTEXT_PASSTHROUGH_ENABLED)
+   seq_printf(m, ",ecryptfs_passthrough");
+   if (mount_crypt_stat->flags & ECRYPTFS_XATTR_METADATA_ENABLED)
+   seq_printf(m, ",ecryptfs_xattr_metadata");
+   if (mount_crypt_stat->flags & ECRYPTFS_ENCRYPTED_VIEW_ENABLED)
+   seq_printf(m, ",ecryptfs_encrypted_view");
+
+   return 0;
 }
 
 struct super_operations ecryptfs_sops = {



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

[PATCH/RFC -rt] local_bh_enable() is safe for irqs_disabled()

[Kevin Hilman]

In local_bh_enable() there is a WARN_ON(irqs_disabled()), but looking
at the rest of the code, it seems it expects to be used with
interrupts off, so is this warning really necessary?

I hit this warning in the ads7846 touchscreen driver timer function
where enable_irq() may be called with interrupts disabled.  Since
enable_irq now calls local_bh_disable/enable for IRQ resend, this
warning is triggered.

Patch against 2.6.23.9-rt12

Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>

diff --git a/kernel/softirq.c b/kernel/softirq.c
index 4c19017..68149ae 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -207,7 +207,6 @@ void local_bh_enable(void)
 
WARN_ON_ONCE(in_irq());
 #endif
-   WARN_ON_ONCE(irqs_disabled());
 
 #ifdef CONFIG_TRACE_IRQFLAGS
local_irq_save(flags);
--
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.22.14 oops msg with commvault galaxy ?

[Randy Dunlap]

On Fri, 7 Dec 2007 15:11:13 -0800 Andrew Morton wrote:

> On Fri, 7 Dec 2007 14:15:36 -0800
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
> 
> > > Help would really be appreciated.
> > 
> > Let's try the last_sysfs_file (name) patch.
> > I've attempted to update it for 2.6.22.14.
> > Andrew, does this change in fs/sysfs/file.c look OK?
> 
> umm, yup.
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/gregkh-driver-sysfs-crash-debugging.patch
> 
> should work.

Thanks.  
I produced a cleanly applying version of it for 2.6.22.14.

Vincent, please apply this patch so we can know which file in sysfs
these oopses are happening with.

---


From: Andrew Morton <[EMAIL PROTECTED]>

Display the most-recently-opened sysfs file's name when oopsing.

From: Adrian Bunk <[EMAIL PROTECTED]>

  Build fix

From: Greg Kroah-Hartman <[EMAIL PROTECTED]>

  Modified to make the api call cleaner, and available to all arches if
  need be.  Also added it to x86-64's crash dump message.


Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 arch/i386/kernel/traps.c   |1 +
 arch/x86_64/kernel/traps.c |1 +
 fs/sysfs/file.c|   14 ++
 include/linux/sysfs.h  |6 ++
 4 files changed, 22 insertions(+)

--- linux-2.6.22.14.orig/arch/i386/kernel/traps.c
+++ linux-2.6.22.14/arch/i386/kernel/traps.c
@@ -411,6 +411,7 @@ void die(const char * str, struct pt_reg
 #endif
if (nl)
printk("\n");
+   sysfs_printk_last_file();
if (notify_die(DIE_OOPS, str, regs, err,
current->thread.trap_no, SIGSEGV) !=
NOTIFY_STOP) {
--- linux-2.6.22.14.orig/arch/x86_64/kernel/traps.c
+++ linux-2.6.22.14/arch/x86_64/kernel/traps.c
@@ -516,6 +516,7 @@ void __kprobes __die(const char * str, s
printk("DEBUG_PAGEALLOC");
 #endif
printk("\n");
+   sysfs_printk_last_file();
notify_die(DIE_OOPS, str, regs, err, current->thread.trap_no, SIGSEGV);
show_registers(regs);
/* Executive summary in case the oops scrolled away */
--- linux-2.6.22.14.orig/fs/sysfs/file.c
+++ linux-2.6.22.14/fs/sysfs/file.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -15,6 +16,13 @@
 
 #define to_sattr(a) container_of(a,struct subsys_attribute, attr)
 
+/* used in crash dumps to help with debugging */
+static char last_sysfs_file[PATH_MAX];
+void sysfs_printk_last_file(void)
+{
+   printk(KERN_EMERG "last sysfs file: %s\n", last_sysfs_file);
+}
+
 /*
  * Subsystem file operations.
  * These operations allow subsystems to have files that can be 
@@ -253,6 +261,12 @@ static int sysfs_open_file(struct inode 
struct sysfs_buffer * buffer;
struct sysfs_ops * ops = NULL;
int error = 0;
+   char *p;
+
+   p = d_path(file->f_dentry, sysfs_mount, last_sysfs_file,
+  sizeof(last_sysfs_file));
+   if (p)
+   memmove(last_sysfs_file, p, strlen(p) + 1);
 
if (!kobj || !attr)
goto Einval;
--- linux-2.6.22.14.orig/include/linux/sysfs.h
+++ linux-2.6.22.14/include/linux/sysfs.h
@@ -125,6 +125,7 @@ void sysfs_remove_file_from_group(struct
const struct attribute *attr, const char *group);
 
 void sysfs_notify(struct kobject * k, char *dir, char *attr);
+void sysfs_printk_last_file(void);
 
 
 extern int sysfs_make_shadowed_dir(struct kobject *kobj,
@@ -240,6 +241,11 @@ static inline int __must_check sysfs_ini
return 0;
 }
 
+static inline void sysfs_printk_last_file(void)
+{
+   ;
+}
+
 #endif /* CONFIG_SYSFS */
 
 #endif /* _SYSFS_H_ */
--
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] arch_ptrace_stop

[Roland McGrath]

This adds support to allow asm/ptrace.h to define two new macros,
arch_ptrace_stop_needed and arch_ptrace_stop.  These control special
machine-specific actions to be done before a ptrace stop.  The new
code compiles away to nothing when the new macros are not defined.
This is the case on all machines to begin with.

On ia64, these macros will be defined to solve the long-standing
issue of ptrace vs register backing store.

Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
CC: Petr Tesarik <[EMAIL PROTECTED]>
CC: Tony Luck <[EMAIL PROTECTED]>
---
 include/linux/ptrace.h |   35 +++
 kernel/signal.c|   33 -
 2 files changed, 67 insertions(+), 1 deletions(-)

diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index ae8146a..7168757 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -128,6 +128,41 @@ int generic_ptrace_pokedata(struct task_struct *tsk, long 
addr, long data);
 #define force_successful_syscall_return() do { } while (0)
 #endif
 
+#ifndef arch_ptrace_stop_needed
+/**
+ * arch_ptrace_stop_needed - Decide whether arch_ptrace_stop() should be called
+ * @code:  current->exit_code value ptrace will stop with
+ * @info:  siginfo_t pointer (or %NULL) for signal ptrace will stop with
+ *
+ * This is called with the siglock held, to decide whether or not it's
+ * necessary to release the siglock and call arch_ptrace_stop() with the
+ * same @code and @info arguments.  It can be defined to a constant if
+ * arch_ptrace_stop() is never required, or always is.  On machines where
+ * this makes sense, it should be defined to a quick test to optimize out
+ * calling arch_ptrace_stop() when it would be superfluous.  For example,
+ * if the thread has not been back to user mode since the last stop, the
+ * thread state might indicate that nothing needs to be done.
+ */
+#define arch_ptrace_stop_needed(code, info)(0)
+#endif
+
+#ifndef arch_ptrace_stop
+/**
+ * arch_ptrace_stop - Do machine-specific work before stopping for ptrace
+ * @code:  current->exit_code value ptrace will stop with
+ * @info:  siginfo_t pointer (or %NULL) for signal ptrace will stop with
+ *
+ * This is called with no locks held when arch_ptrace_stop_needed() has
+ * just returned nonzero.  It is allowed to block, e.g. for user memory
+ * access.  The arch can have machine-specific work to be done before
+ * ptrace stops.  On ia64, register backing store gets written back to user
+ * memory here.  Since this can be costly (requires dropping the siglock),
+ * we only do it when the arch requires it for this particular stop, as
+ * indicated by arch_ptrace_stop_needed().
+ */
+#define arch_ptrace_stop(code, info)   do { } while (0)
+#endif
+
 #endif
 
 #endif
diff --git a/kernel/signal.c b/kernel/signal.c
index afa4f78..2e85fcb 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1594,6 +1594,17 @@ static inline int may_ptrace_stop(void)
 }
 
 /*
+ * Return nonzero if there is a SIGKILL that should be waking us up.
+ * Called with the siglock held.
+ */
+static int sigkill_pending(struct task_struct *tsk)
+{
+   return ((sigismember(&tsk->pending.signal, SIGKILL) ||
+sigismember(&tsk->signal->shared_pending.signal, SIGKILL)) &&
+   !unlikely(sigismember(&tsk->blocked, SIGKILL)));
+}
+
+/*
  * This must be called with current->sighand->siglock held.
  *
  * This should be the path for all ptrace stops.
@@ -1606,6 +1617,26 @@ static inline int may_ptrace_stop(void)
  */
 static void ptrace_stop(int exit_code, int nostop_code, siginfo_t *info)
 {
+   int killed = 0;
+
+   if (arch_ptrace_stop_needed(exit_code, info)) {
+   /*
+* The arch code has something special to do before a
+* ptrace stop.  This is allowed to block, e.g. for faults
+* on user stack pages.  We can't keep the siglock while
+* calling arch_ptrace_stop, so we must release it now.
+* To preserve proper semantics, we must do this before
+* any signal bookkeeping like checking group_stop_count.
+* Meanwhile, a SIGKILL could come in before we retake the
+* siglock.  That must prevent us from sleeping in TASK_TRACED.
+* So after regaining the lock, we must check for SIGKILL.
+*/
+   spin_unlock_irq(¤t->sighand->siglock);
+   arch_ptrace_stop(exit_code, info);
+   spin_lock_irq(¤t->sighand->siglock);
+   killed = sigkill_pending(current);
+   }
+
/*
 * If there is a group stop in progress,
 * we must participate in the bookkeeping.
@@ -1621,7 +1652,7 @@ static void ptrace_stop(int exit_code, int nostop_code, 
siginfo_t *info)
spin_unlock_irq(¤t->sighand->siglock);
try_to_freeze();
read_lock(&tasklist_lock);
-   if (may_ptrace_stop()) {
+   

Re: [git pull] x86/hrtimer/acpi fixes

[Fernando Lopez-Lezcano]

On Fri, 2007-12-07 at 20:59 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> 
> > > Nope, it doesn't still getting "delay" and "xrun" messages galore.
> > 
> > Attached: configuration and dmesg output booting with idle=poll, 
> > reconfirmed that that makes the delay and xrun messages go away.
> 
> could you try the rolled up patch of various fixlets, ontop of current 
> -git? (it might even apply to -rc4) It includes some more stuff beyond 
> the ones in the pull request. (still being tested/reviewed)

I'll try but it will take me a while to figure git and do a package
build of it...

-- Fernando


--
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] scheduler: fix x86 regression in native_sched_clock

[Nick Piggin]

On Saturday 08 December 2007 11:50, Nick Piggin wrote:

> I guess your patch is fairly complex but it should work

I should also add that although complex, it should have a
much smaller TSC delta window in which the wrong scaling
factor can get applied to it (I guess it is about as good
as you can possibly get). So I do like it :)
--
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 5/7] Security: Change current->fs[ug]id to current_fs[ug]id()

[David Howells]

Serge E. Hallyn <[EMAIL PROTECTED]> wrote:

> Could you resend patch 6?

As I said in the cover note:

A tarball of the patches is available at:


http://people.redhat.com/~dhowells/fscache/patches/nfs+fscache-25.tar.bz2

David
--
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 manage shared persistent local caching (FS-Cache) with NFS?

[David Howells]

Chuck Lever <[EMAIL PROTECTED]> wrote:

> Why not encode the local mounted-on directory in the key?

Can't.  Namespaces.  chroot.

> Meaning your cache is at quota all the time, and to continue operation it must
> eject items constantly.

I've thought about that, thank you.  Go and read the documentation.  There's
configurable hysteresis in the culling algorithm.

> This is a scenario where it pays to cache the read-mostly items on disk, and
> leave the frequently changing items in memory.

Currently any file which is opened for writing is automatically ejected from
the cache.

> The economics of disk caches is different than memory caches.  Disk caches are
> much larger and cheaper, but their performance tanks when  they have to track
> frequently changing files.  Memory caches are  smaller, but tracking
> frequently changing data is only a little more  expensive than tracking data
> that doesn't change often.

I'm aware of all that.  My OLS slides and paper can be found here:

http://people.redhat.com/~dhowells/fscache/fscache-ols2006.odp
http://people.redhat.com/~dhowells/fscache/FS-Cache.pdf

Lots of small files also hurt worse than fewer big files in some ways.  Lots
more metadata in the cache.  On the other hand, fragmentation is less of a
problem.

Anyway, this is straying off the main topic.

> I think it's key to preventing FS-cache from making performance worse in many
> common scenarios.

Perhaps.  The problem is that NFS doesn't know what the access pattern on a
file is expected to be.  I've been asked to provide fine-grained cache
controls (perhaps directory level), but Al Viro was, erm, luke warm in his
reception to that idea.

Gathering statistical data dynamically has performance penalties of its own:-/

> Disconnected operation for NFS is fraught with challenges.  Access to data on
> servers is traditionally gated by the client's IP address,  for example.  The
> client may disconnect from the network, then  reconnect using a different
> address where suddenly all of its  accesses are rebuffed.

Agreed, but isn't that one of the design goals for NFS4?

It's also something of interest to other netfs's that might want to use
FS-Cache.  This isn't an NFS-only facility.

> NFS servers, not clients, traditionally determine the file's mtime and ctime,
> and its file handle.  So file updates and file creation  become problematic.
> The client has to reconcile the server's file  handle, for files created
> offline, with its own when reconnecting.

Yes.  Basically it's a major can of major worms.  Doesn't stop people wanting
it, though.

> And, for disconnected operation, the cache is required to contain every item
> from the remote.  You can't just drop items from the cache  because they are
> inconvenient.

Yes.  That's what pinning and reservations are for.

Currently, support for disconnected operations is an idea I'd like to have,
but is otherwise mostly non-existent.

> That something might be the pathname of the mounted-on directory or of the
> file itself.

See above.

> Yes, they do.  The combination of mount options and mounted-on directory (or
> local pathname to the file) gives you a unique identity  for that view.

See above.

> So an item is cached in memory until space becomes available in the disk
> cache?

The item isn't considered for caching until space becomes available in the
disk cache.  It's put on a queue for potential caching, but won't actually be
cached if it gets discarded from the icache or pagecache before being cached.

It's unfortunate, but with a fast network you can download data faster than
you can make space in the cache.  unlink() and rmdir() are (a) slow and (b)
synchronous.  Each unlink() or rmdir() operation requires a task to perform
it, and that task is committed until the op finishes.

I could actually improve cachefilesd (the userspace cache culler) by giving it
multiple threads.

However, having cachefilesd doing lots of parallel synchronous, journalled
disk ops hurts performance in other ways I've noticed:-/

Again, hysteresis is available.  We stop writing stuff into the cache beyond
a limit until the free space drops sufficiently below that limit that we've
got a good go at writing a load new stuff, rather than just a block here and a
block there.

It's all very icky, and depends as much on the filesystem underlying the cache
(ext3 for example) and *its* configuration, as the characteristics of the
netfs and the network link.  It's all about compromise.

David
--
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] scheduler: fix x86 regression in native_sched_clock

[Nick Piggin]

On Saturday 08 December 2007 03:48, Nick Piggin wrote:
> On Friday 07 December 2007 22:17, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > ah, printk_clock() still uses sched_clock(), not jiffies. So it's
> > > > not the jiffies counter that goes back and forth, it's sched_clock()
> > > > - so this is a printk timestamps anomaly, not related to jiffies. I
> > > > thought we have fixed this bug in the printk code already:
> > > > sched_clock() is a 'raw' interface that should not be used directly
> > > > - the proper interface is cpu_clock(cpu).
> > >
> > > It's a single CPU box, so sched_clock() jumping would still be
> > > problematic, no?
> >
> > sched_clock() is an internal API - the non-jumping API to be used by
> > printk is cpu_clock().
>
> You know why sched_clock jumps when the TSC frequency changes, right?

Ah, hmm, I don't know why I wrote that :)

I guess your patch is fairly complex but it should work if the plan
is to convert all sched_clock users to use cpu_clock eg like lockdep
as well.

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

Re: HTC TyTN || (P4550) violates GPL?? Or maybe Qualcomm itself with MSM7200???

[Mauricio Mauad Menegaz Filho]

2007/12/7, CIJOML <[EMAIL PROTECTED]>:
> Hi there,
> ...
> Can anybody else confirm this and contact those companies for source codes?
>

It seems that the sources are there:

http://www.ertos.nicta.com.au/software/


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

Re: [patch 1/2] Kprobes: Indicate kretprobe support in arch//Kconfig

[Andrew Morton]

On Tue, 13 Nov 2007 21:17:10 +0530
Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote:

> From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
> 
> This patch adds CONFIG_ARCH_SUPPORTS_KRETPROBES to the
> arch//Kconfig file for relevant architectures with kprobes
> support. This facilitates easy handling of in-kernel modules (like
> samples/kprobes/kretprobe_example.c) that depend on kretprobes being
> present in the kernel.
> 
> This patch depends on Mathieu Desnoyers' "Instrumentation menu removal"
> patchset (http://marc.info/?l=linux-kernel&m=119496432229633&w=2)

I didn't merge this because I didn't merge Mathieu's patches because my brain
is not large enough to keep up with Mathieu's patches so sparc64 is still
busted.

Please send fixes against 2.6.24-rc4-mm1?

Thanks.
--
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 07/18] v4l: nopage

[Andrew Morton]

On Wed, 05 Dec 2007 18:15:54 +1100
[EMAIL PROTECTED] wrote:

> +static int
> +videobuf_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>   struct page *page;
>  
> - dprintk(3,"nopage: fault @ %08lx [vma %08lx-%08lx]\n",
> - vaddr,vma->vm_start,vma->vm_end);
> - if (vaddr > vma->vm_end)
> - return NOPAGE_SIGBUS;
> + dprintk(3,"fault: fault @ %08lx [vma %08lx-%08lx]\n",
> + (unsigned long)vmf->virtual_address,vma->vm_start,vma->vm_end);
>   page = alloc_page(GFP_USER | __GFP_DMA32);
>   if (!page)
> - return NOPAGE_OOM;
> + return VM_FAULT_OOM;
>   clear_user_page(page_address(page), vaddr, page);

This didn't compile on sparc64 because `vaddr' is undefined.


Let us see why:

#define clear_user_page(page, vaddr, pg)clear_page(page)
#define copy_user_page(to, from, vaddr, pg) copy_page(to, from)

#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)

root cause: lack of argument checking on x86 due to stupid macros.


Could someone *please* start a little project of extirpating this utter
brain damage?  Convert those macros to typechecked static inlines on x86
(at least) so this sort of thing (which happens again and again and again)
is lessened?


macros are such miserable things.  I wonder if we could get checkpatch to
help out here?  
--
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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

[Andi Kleen]

On Wed, Dec 05, 2007 at 11:10:39AM +, Pavel Machek wrote:
> On Fri 2007-12-07 09:50:26, David P. Reed wrote:
> > My machine in question, for example, needs no waiting 
> > within CMOS_READs at all.   And I doubt any other 
> > chip/device needs waiting that isn't already provided by 
> > the bus. the i/o to port 80 is very, very odd in this 
> > context.  Actually, modern machines have potentially 
> > more serious problems with i/o ops to non-existent 
> > addresses, which may cause real bus wierdness.
> 
> I dislike outb_p clobbering port 0x80, but you are wrong here. BIOSes
> already do outs to port 0x80 for debugging reason, so these accesses
> are unlikely to do something bad.

They only do that briefly during boot though. But Linux
can do it much more often. If it's a race
or similar it might just not trigger with the BIOS.

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

HTC TyTN || (P4550) violates GPL?? Or maybe Qualcomm itself with MSM7200???

[CIJOML]

Hi there,

it looks like there is running linux somewhere inside in the radio part of the 
firmware...

http://forum.xda-developers.com/archive/index.php/t-326419.html

$ strings kaiser_radio_0x301.nb |grep -i linux
 M6500C L4/Linux
 L4 Linux
 NICTNICTA::Pistachio - built on Jan 23 2007 18:10:22 by [EMAIL PROTECTED] 
using gcc version 3.4.1
 start_linux_cmd
 vmlinux != NULL
 vmlinux
 vmlinux igms_name=ramdisk root=/dev/igms0
 start_linux

Can anybody else confirm this and contact those companies for source codes?

Thanks a lot!

Michal
--
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.24-rc3-git4 NFS crossmnt regression

[Andrew Morton]

On Sat, 8 Dec 2007 03:00:43 +0300
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:

> On Sat, Dec 08, 2007 at 12:43:28AM +0100, Rafael J. Wysocki wrote:
> > On Saturday, 8 of December 2007, Andrew Morton wrote:
> > > On Fri, 07 Dec 2007 17:51:58 -0500
> > > Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > > 
> > > > 
> > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > > On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote:
> > > > > ...
> > > > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few 
> > > > > > more
> > > > > > spots and check for other regressions.
> > > > > 
> > > > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > > > server. And now I don't see anything at all in the crossmnt dirs.
> > > > > 
> > > > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > > > 
> > > > > Are there any other pending fixes?
> > > > > 
> > > > > Shane
> > > > 
> > > > You've probably fallen afoul of 
> > > > 
> > > >http://bugzilla.kernel.org/show_bug.cgi?id=9504
> > > > 
> > > 
> > > Yeah.
> > > 
> > > I have a tentative fix below but I can't seem to get Eric and Denis to get
> > > a suitable fix nailed down.  It's urgent!
> > 
> > Well, how about asking Linus to revert commit
> > 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over again?
> > 
> > It apparently causes more trouble than the issue it was supposed to fix.
> 
> I very much agree. ->shadow_proc is so ugly, so it's not funny anymore.
> Adding such hook for proc part of networking _and_ for modules is just asking
> for trouble as was demonstrated.

OK, perhaps a revert is the best thing to do here.  I don't think anyone
will be expecting fully finalised and robust netns support in 2.6.24.

Eric?
--
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: [Bluez-users] Lost connections - mouse and keyboard

[Didier Link]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le Fri, 30 Nov 2007 09:06:52 +0800,
"Dave Young" <[EMAIL PROTECTED]> a écrit :

> On Nov 30, 2007 4:43 AM, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> > On Thu, 29 Nov 2007, Marcel Holtmann wrote:
> >

Hi all,

Just for add something on this bug report, I've the same hardware
(Logitech dinovo keyboard+mouse), connected with bluetooth
hcid/bluetoothd-service-input

First of all, this work very well at first run and all the time I
interact with keyboard and mouse, very good job of the bluez stack
developpers !

But, like Brad, after an amount of inactivity (about 20 minutes
I think ...) the devices go to sleep mode and never reconnect. I need to
restart the bluetooth service at all, with another usb keyboard. My
kernel log contain the same warnings as Brad each time the service is
restarted.

Some times I've a kernel oops that kill khidp and I never can use
keyboard and mouse, need to reboot the computer ... of course I've
tried to unload the modules concerned but it's impossible.

I attach the lines of this oops for kernel hackers.

My kernel is the last 2.6.23 and I run a Gentoo up to date (bluez-libs
and utils 3.22), on an AMD64 dual core processor with 2GB of ram. The
kernel is tainted by the nvidia proprietary driver, sorry :-/ ... 

the result of 'cat /proc/bus/input/devices' for the bt devices is also
attached.

I will try to use the latest patch (2.6.23-mh1) from the bluez download
site tomorrow.

This problem is present since monthes for me but just a service restart
isn't so hard to do ... but the oppsses are so annoying and more
frequent these days !!

Thanks for your attention, I hope you can solve this issue easily and
if you need some more datas and results of tests just ask me !

Best regards.

Didier LINK

- -- 
Didier Link <[EMAIL PROTECTED]>
Jabber : [EMAIL PROTECTED]
MSN : [EMAIL PROTECTED]
SIP : [EMAIL PROTECTED]

Clé GPG : 75BAC9EE
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHWdpvkyPwinW6ye4RApiTAJ0XX2jUzT1wAT9se7jQIzHejQ5DPgCfeYF3
YCsIEHHPGM6/NoOxQd7hEQc=
=1D17
-END PGP SIGNATURE-
Dec  7 22:56:28 neutrino kernel: Unable to handle kernel paging request at 
00100100 RIP: 
Dec  7 22:56:28 neutrino kernel: [] 
:evdev:evdev_disconnect+0x7e/0xb8
Dec  7 22:56:28 neutrino kernel: PGD 7730f067 PUD 77cb5067 PMD 0 
Dec  7 22:56:28 neutrino kernel: Oops:  [1] PREEMPT SMP 
Dec  7 22:56:28 neutrino kernel: CPU 0 
Dec  7 22:56:28 neutrino kernel: Modules linked in: nls_utf8 ntfs nls_iso8859_1 
nls_cp437 vfat fat w83627hf hwmon_vid eeprom hci_usb nfsd exportfs lockd 
nfs_acl auth_rpcgss sunrpc ipv6 aes ieee80211_crypt_ccmp ipt_LOG xt_limit 
xt_tcpudp xt_state xt_multiport iptable_filter iptable_nat nf_nat 
nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables x_tables snd_seq_midi 
snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss 
snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq uinput ppp_generic slhc 
rfcomm hidp l2cap bluetooth dm_mod forcedeth af_packet snd_usb_audio 
snd_usb_lib usblp usbhid hid usb_storage nvidia(P) snd_emu10k1 snd_rawmidi 
snd_ac97_codec ac97_bus bcm43xx snd_pcm firmware_class snd_seq_device snd_timer 
snd_page_alloc ieee80211softmac ohci1394 snd_util_mem ieee80211 snd_hwdep 
8250_pnp ieee1394 ide_cd cdrom k8temp evdev 8250 hwmon snd sky2 ieee80211_crypt 
serial_core emu10k1_gp gameport i2c_nforce2 ohci_hcd ehci_hcd soundcore unix
Dec  7 22:56:28 neutrino kernel: Pid: 9281, comm: khidpd_046db003 Tainted: P
2.6.23-gentoo-r3 #1
Dec  7 22:56:28 neutrino kernel: RIP: 0010:[]  
[] :evdev:evdev_disconnect+0x7e/0xb8
Dec  7 22:56:28 neutrino kernel: RSP: 0018:81006721fdf0  EFLAGS: 00010216
Dec  7 22:56:28 neutrino kernel: RAX:  RBX: 000ffae8 
RCX: 810003012f80
Dec  7 22:56:28 neutrino kernel: RDX:  RSI: 810071031040 
RDI: 810003012f80
Dec  7 22:56:28 neutrino kernel: RBP: 81007ae83c00 R08: 81006721e000 
R09: 810003010f68
Dec  7 22:56:28 neutrino kernel: R10: 0002 R11:  
R12: 81007ae83c88
Dec  7 22:56:28 neutrino kernel: R13: 81007ae83c98 R14: 810066cc0400 
R15: 810071177878
Dec  7 22:56:28 neutrino kernel: FS:  2b0e6d46e6f0() 
GS:81365000() knlGS:
Dec  7 22:56:28 neutrino kernel: CS:  0010 DS:  ES:  CR0: 
8005003b
Dec  7 22:56:28 neutrino kernel: CR2: 00100100 CR3: 77818000 
CR4: 06e0
Dec  7 22:56:28 neutrino kernel: DR0:  DR1:  
DR2: 
Dec  7 22:56:28 neutrino kernel: DR3:  DR6: 0ff0 
DR7: 0400
Dec  7 22:56:28 neutrino kernel: Process khidpd_046db003 (pid: 9281, threadinfo 
81006721e000, task 810071031040)
Dec  7 22:56:28 neutrino kernel: Stack:  81122783 81007de5a000 
81007de5a910 81007de5a938
Dec  7 22:56:28 neutrino kernel: 81006ed4e800 811d

Re: [PATCH 2/2] cxgb3 - Parity initialization for T3C adapters

[Divy Le Ray]

Jeff Garzik wrote:


Divy Le Ray wrote:
> Jeff Garzik wrote:
>> Divy Le Ray wrote:
>>> From: Divy Le Ray <[EMAIL PROTECTED]>
>>>
>>> Add parity initialization for T3C adapters.
>>>
>>> Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
>>> ---
>>>
>>>  drivers/net/cxgb3/adapter.h   |1
>>>  drivers/net/cxgb3/cxgb3_main.c|   82 
>>>  drivers/net/cxgb3/cxgb3_offload.c |   15 ++
>>>  drivers/net/cxgb3/regs.h  |  248
>>> +
>>>  drivers/net/cxgb3/sge.c   |   24 +++-
>>>  drivers/net/cxgb3/t3_hw.c |  131 +---
>>>  6 files changed, 472 insertions(+), 29 deletions(-)
>>
>> dropped patches 2-3, did not apply
>>
>>
>
> Hi Jeff,
>
> I noticed that you applied the first one of this 3 patches series to the
> #upstream-fixes branch.
> These patches are intended to the #upstream (2.6.25) branch, as they are
> built on top of the
> last 10 patches committed - 9 from me, and the white space clean up
> (thanks!).
> May be this is the reason why they did not apply.

Ah... you need to tell me these things.  I looked for a kernel version
in your messages but did not see one.

I had put it in the introduction mail, I should have added the kernel 
version in the patch titles.

I'll do from now on.



Does the patch #1 need to be reverted for 2.6.24?


No, it can be applied to 2.6.24.
The 2 next patches seem to apply cleanly on #upstream when patch #1 is 
popped out the patch stack.




> On this topic, I have a question: how do I get to see all the netdev-2.6
> branches ?


git fetch -f $NETDEV_URL upstream:upstream

copies the latest upstream branch from netdev-2.6.git, and stores it as
your local upstream branch.

You may do the same for #upstream-fixes too.



That made it.
Thanks a lot!

Cheers,
Divy
--
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.24-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64

[Andrew Morton]

On Sat, 8 Dec 2007 01:04:55 +0100
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:

> Hello,
> 
>   I tried it on sun ultra 60 (dual sparc64) station. Unfortunately it 
> failed
> to compile.
> 
>   AS  arch/sparc64/lib/xor.o
>   AR  arch/sparc64/lib/lib.a
>   GEN .version
>   CHK include/linux/compile.h
> dnsdomainname: Unknown host
>   UPD include/linux/compile.h
>   CC  init/version.o
>   LD  init/built-in.o
>   LD  .tmp_vmlinux1
> arch/sparc64/kernel/head.o: In function `sys_call_table32':
> arch/sparc64/kernel/head.S:(.text+0x224e0): undefined reference to 
> `compat_sys_timerfd'
> make: *** [.tmp_vmlinux1] Error 1

argh, sorry, I am soo fed up with fixing that patch.

--- a/arch/sparc64/kernel/systbls.S~timerfd-v3-new-timerfd-api-sparc64-fix
+++ a/arch/sparc64/kernel/systbls.S
@@ -80,7 +80,7 @@ sys_call_table32:
.word sys_fchmodat, sys_faccessat, compat_sys_pselect6, 
compat_sys_ppoll, sys_unshare
 /*300*/.word compat_sys_set_robust_list, compat_sys_get_robust_list, 
compat_sys_migrate_pages, compat_sys_mbind, compat_sys_get_mempolicy
.word compat_sys_set_mempolicy, compat_sys_kexec_load, 
compat_sys_move_pages, sys_getcpu, compat_sys_epoll_pwait
-/*310*/.word compat_sys_utimensat, compat_sys_signalfd, 
compat_sys_timerfd, sys_eventfd, compat_sys_fallocate
+/*310*/.word compat_sys_utimensat, compat_sys_signalfd, 
sys_ni_syscall, sys_eventfd, compat_sys_fallocate
 
 #endif /* CONFIG_COMPAT */
 
_

Or should this have been sys_nis_syscall()?


I should have picked this up in cross-build testing but iirc
sparc64 broke for other reasons.  Let me check on that.
--
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] kbuild: implement modules.order

[Tejun Heo]

Adrian Bunk wrote:
> On Tue, Dec 04, 2007 at 10:49:37PM +0900, Tejun Heo wrote:
>> When multiple built-in modules (especially drivers) provide the same
>> capability, they're prioritized by link order specified by the order
>> listed in Makefile.  This implicit ordering is lost for loadable
>> modules.
>> ...
> 
> What exactly are the drivers you are thinking of?
> 
> I would rather see us getting away from any link order dependencies.
> 
> E.g. we might one day want to compile the whole kernel with one gcc call 
> (using "--combine -fwhole-program").

The following bugzilla triggered this change and I think contains enough
discussion on the subject.

  http://bugzilla.kernel.org/show_bug.cgi?id=8933

Thanks.

-- 
tejun
--
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.24-rc3-git4 NFS crossmnt regression

[Alexey Dobriyan]

On Sat, Dec 08, 2007 at 12:43:28AM +0100, Rafael J. Wysocki wrote:
> On Saturday, 8 of December 2007, Andrew Morton wrote:
> > On Fri, 07 Dec 2007 17:51:58 -0500
> > Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > 
> > > 
> > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > > On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote:
> > > > ...
> > > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > > > spots and check for other regressions.
> > > > 
> > > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > > server. And now I don't see anything at all in the crossmnt dirs.
> > > > 
> > > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > > 
> > > > Are there any other pending fixes?
> > > > 
> > > > Shane
> > > 
> > > You've probably fallen afoul of 
> > > 
> > >http://bugzilla.kernel.org/show_bug.cgi?id=9504
> > > 
> > 
> > Yeah.
> > 
> > I have a tentative fix below but I can't seem to get Eric and Denis to get
> > a suitable fix nailed down.  It's urgent!
> 
> Well, how about asking Linus to revert commit
> 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over again?
> 
> It apparently causes more trouble than the issue it was supposed to fix.

I very much agree. ->shadow_proc is so ugly, so it's not funny anymore.
Adding such hook for proc part of networking _and_ for modules is just asking
for trouble as was demonstrated.
--
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.24-rc4-mm1 and /proc//status Name: field

[Andrew Morton]

On Fri, 07 Dec 2007 20:26:43 +
Zan Lynx <[EMAIL PROTECTED]> wrote:

> Today I noticed pgrep doesn't work.  It seems the reason is a missing
> Name: tag in the status file for a process in /proc.
> 
> # cat /proc/1/status
> init
> State:  S (sleeping)
> Tgid:   1
> Pid:1
> PPid:   0
> TracerPid:  0
> ...etc, etc...
> 
> This is supposed to look like:
> # cat /proc/1/status
> Name: init
> State:S (sleeping)
> Tgid: 1
> Pid:  1
> PPid: 0
> TracerPid:0
> ...
> 

Thanks.  Two (more) bugs in
proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces.patch

--- 
a/fs/proc/array.c~proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-fix-3
+++ a/fs/proc/array.c
@@ -98,9 +98,9 @@ static inline void task_name(struct seq_
 
get_task_comm(tcomm, p);
 
+   seq_printf(m, "Name:\t");
end = m->buf + m->size;
buf = m->buf + m->count;
-   seq_printf(m, "Name:\n");
name = tcomm;
i = sizeof(tcomm);
while (i && (buf < end)) {
_

--
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.24-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64

[Mariusz Kozlowski]

Hello,

I tried it on sun ultra 60 (dual sparc64) station. Unfortunately it 
failed
to compile.

  AS  arch/sparc64/lib/xor.o
  AR  arch/sparc64/lib/lib.a
  GEN .version
  CHK include/linux/compile.h
dnsdomainname: Unknown host
  UPD include/linux/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  .tmp_vmlinux1
arch/sparc64/kernel/head.o: In function `sys_call_table32':
arch/sparc64/kernel/head.S:(.text+0x224e0): undefined reference to 
`compat_sys_timerfd'
make: *** [.tmp_vmlinux1] Error 1

Any hints?

Regards,

Mariusz

Linux sparc64 2.6.23-gentoo-r3 #4 SMP PREEMPT Sat Dec 8 00:50:12 CET 2007 
sparc64 sun4u TI UltraSparc II  (BlackBird) GNU/Linux
 
Gnu C  4.1.1
Gnu make   3.81
binutils   2.17
util-linux 2.12r
mount  2.12r
module-init-tools  3.2.2
e2fsprogs  1.39
Linux C Library2.5
Dynamic linker (ldd)   2.5
Procps 3.2.6
Net-tools  1.60
Kbd1.12
Sh-utils   6.4
udev   104
Modules Loaded sr_mod cdrom sg

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc4-mm1
# Sat Dec  8 01:01:01 2007
#
CONFIG_SPARC=y
CONFIG_SPARC64=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_64BIT=y
CONFIG_MMU=y
CONFIG_QUICKLIST=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_OF=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_SPARC64_PAGE_SIZE_8KB=y
# CONFIG_SPARC64_PAGE_SIZE_64KB is not set
# CONFIG_SPARC64_PAGE_SIZE_512KB is not set
# CONFIG_SPARC64_PAGE_SIZE_4MB is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_HOTPLUG_CPU is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
# CONFIG_CGROUPS is not set
# CONFIG_FAIR_GROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
CONFIG_SYSVIPC_COMPAT=y
CONFIG_GENERIC_HARDIRQS=y

#
# General machine setup
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_NR_CPUS=4
# CONFIG_CPU_FREQ is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=0
CONFIG_NR_QUICK=1
CONFIG_SBUS=y
CONFIG_SBUSCHAR=y
CONFIG_SUN_AUXIO=y
CONFIG_SUN_IO=y
# CONFIG_SUN_LDOMS is not set
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_SYSCALL=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG i

ata_piix init/performance regression ?

[devzero]

Hello !

on my old fujitsu-siemens lifebook, booting is at least 20 seconds slower as 
before.

on ata_piix init i can see 2 longer delays of ~10 seconds each, which didn`t 
happen before.

i`m using SuSE kernel of the day from 
http://ftp.suse.com/pub/projects/kernel/kotd/

problem exists with these kernels:
kernel-vanilla-2.6.24_rc3_git3-20071201095839
kernel-default-2.6.24_rc3_git3-20071201095839
kernel-default-2.6.24_rc4_git3-20071206172629
kernel-vanilla-2.6.24_rc4_git3-20071206172629

problem didn`t exist with this one:
kernel-default-2.6.22.12-0.1 (opensuse 10.3 default)

please see https://bugzilla.novell.com/show_bug.cgi?id=345442 for more details.

regards
roland

_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=0066

--
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: programs vanish with 2.6.22+

[Guennadi Liakhovetski]

On Fri, 7 Dec 2007, Markus wrote:

> Well, now some windows vanished, but no additional messages were 
> produced by kernel. When somebody could tell what I exactly need to 
> do... would be nice.
> Or a hit, in what direction I should look. Because its really nasty to 
> not being able to use a current kernel.
> 
> I already rebuild the whole system, as suggested by the gentoo-devs, 
> without success.
> 
> I could also try to debug/strace/whatever the apps and wait for it to 
> disappear.

Well, you could attach strace to all likely crash candidates like

strace -etrace=none -o/tmp/.trace -p

which would at least tell you what signal it caught...

good luck
Guennadi

> 
> Just talk to me, I am not able to do this on my own...
> 
> 
> Markus
> 
> > On Fri, 7 Dec 2007, Markus wrote:
> > 
> > > Hi again!
> > > 
> > > The memtest ran 14 passes (~10h) without an error.
> > > 
> > > I now have a 2.6.24-rc4 with some debug-options turned on, waiting 
> for 
> > > something to happen... can I just leave it untill a window 
> disappears 
> > > or do I need to manually enable something or run some user-space 
> app?!
> > 
> > It depends - different options have it differently. Most simple ones 
> are 
> > just compile-time, so, you don't have to enable them. Look in "help" 
> for 
> > respective debug-options.
> > 
> > Thanks
> > Guennadi
> > ---
> > Guennadi Liakhovetski
> > 
> 
> 

---
Guennadi Liakhovetski
--
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.24-rc4-mm1 and Very Slow PCMCIA Compact Flash

[Zan Lynx]

On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote:
> On Fri, 07 Dec 2007 23:09:43 +
> Zan Lynx <[EMAIL PROTECTED]> wrote:
> 
> > 
> > On Fri, 2007-12-07 at 15:02 -0800, Andrew Morton wrote:
> > > On Fri, 07 Dec 2007 20:38:24 +
> > > Zan Lynx <[EMAIL PROTECTED]> wrote:
> > > 
> > > > While I'm reporting problems I'll get this one out there.
> > > > 
> > > > I normally use a USB-2 memory card reader but I also have a PCMCIA
> > > > CompactFlash adapter that I use occasionally.  During the MM series
> > > > kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all.  I
> > > > don't know about vanilla since I don't run that.
> > > > 
> > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I
> > > > only get read rates of 1.6 MB/s.  When it used to work in 2.6.20 I got
> > > > at least 16 MB/s.  The card itself is capable of 30+ in the USB-2
> > > > reader.
> > > >
> > 
[cut]
> Oh, OK.  Hopefully the ata guys can help out with this.
> 
> I don't know if it actually strictly a regression?  Did libata ever support
> that device in any earlier kernels?

That could be why it didn't work for a few kernel versions.  I
reconfigured for a libata-only system a while back.  And, since I
usually use the USB-2 flash reader I didn't care much about the PCMCIA.

I will try reverting that patch later tonight, in a few hours.
-- 
Zan Lynx <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: 2.6.24-rc3-git4 NFS crossmnt regression

[Eric W. Biederman]

Andrew Morton <[EMAIL PROTECTED]> writes:

> On Fri, 07 Dec 2007 17:51:58 -0500
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
>> 
>> On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
>> > On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote:
>> > ...
>> > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
>> > > spots and check for other regressions.
>> > 
>> > Hmm, I installed a new kernel built from the same sources on the NFS
>> > server. And now I don't see anything at all in the crossmnt dirs.
>> > 
>> > ls /dirA/dirB/dirC  --> zero output (empty dir)
>> > 
>> > Are there any other pending fixes?
>> > 
>> > Shane
>> 
>> You've probably fallen afoul of 
>> 
>>http://bugzilla.kernel.org/show_bug.cgi?id=9504
>> 
>
> Yeah.
>
> I have a tentative fix below but I can't seem to get Eric and Denis to get
> a suitable fix nailed down.  It's urgent!

Andrew, if it is truly urgent please grab either fix, as they will sort
out the worst of the symptoms.

Mine is a little more thorough, and possibly a little less performant.
However since mounts don't appear to be residing under /proc/net it
isn't a significant issue.

> From: "Denis V. Lunev" <[EMAIL PROTECTED]>
>
> /proc/sys/fs/binfmt_misc dentry disappeared during d_revalidate. 
> d_revalidate only dentries from shadowed one and below. 
> http://bugzilla.kernel.org/show_bug.cgi?id=9504
>
> Cc: Eric W. Biederman <[EMAIL PROTECTED]>
> Cc: Marcus Better <[EMAIL PROTECTED]>
> Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
> Cc: Marcus Better <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
>
>  fs/proc/generic.c |   14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff -puN fs/proc/generic.c~lost-content-of-proc-sys-fs-binfmt_misc
> fs/proc/generic.c
> --- a/fs/proc/generic.c~lost-content-of-proc-sys-fs-binfmt_misc
> +++ a/fs/proc/generic.c
> @@ -380,12 +380,17 @@ static int proc_revalidate_dentry(struct
>   return 0;
>  }
>  
> -static struct dentry_operations proc_dentry_operations =
> +static struct dentry_operations proc_dentry_shadow_operations =
>  {
>   .d_delete   = proc_delete_dentry,
>   .d_revalidate   = proc_revalidate_dentry,
>  };
>  
> +static struct dentry_operations proc_dentry_operations =
> +{
> + .d_delete   = proc_delete_dentry,
> +};
> +
>  /*
>   * Don't create negative dentries here, return -ENOENT by hand
>   * instead.
> @@ -394,6 +399,7 @@ struct dentry *proc_lookup(struct inode 
>  {
>   struct inode *inode = NULL;
>   struct proc_dir_entry * de;
> + int use_shadow = 0;
>   int error = -ENOENT;
>  
>   lock_kernel();
> @@ -406,8 +412,10 @@ struct dentry *proc_lookup(struct inode 
>   if (!memcmp(dentry->d_name.name, de->name, de->namelen))
> {
>   unsigned int ino;
>  
> - if (de->shadow_proc)
> + if (de->shadow_proc) {
>   de = de->shadow_proc(current, de);
> + use_shadow = 1;
> + }
>   ino = de->low_ino;
>   de_get(de);
>   spin_unlock(&proc_subdir_lock);
> @@ -423,6 +431,8 @@ struct dentry *proc_lookup(struct inode 
>  
>   if (inode) {
>   dentry->d_op = &proc_dentry_operations;
> + dentry->d_op = use_shadow ?
> + &proc_dentry_shadow_operations : dentry->d_parent->d_op;
>   d_add(dentry, inode);
>   return NULL;
>   }
> _
--
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.24-rc4-mm1 and excessive block IO errors

[Alexey Dobriyan]

On Fri, Dec 07, 2007 at 03:05:37PM -0800, Andrew Morton wrote:
> On Fri, 07 Dec 2007 20:44:45 +
> Zan Lynx <[EMAIL PROTECTED]> wrote:
> 
> > I am not sure if this problem has been addressed already.  I read some
> > about the fast-fail issues and this may be related?
> > 
> > On nearly all my USB block devices, I have been getting zillions of I/O
> > errors.  But they aren't real, they don't appear with 2.6.23 kernels.
> > 
> > I can often read and write data to the device, but these IO errors cause
> > error aborts in user space applications in many cases, making it a
> > chancy thing to run backup software, for example.
> > 
> > Here is a bit of dmesg from plugging in a perfectly good USB-2 flash
> > drive.
> > 
> > hub 3-0:1.0: state 7 ports 6 chg  evt 0004
> > ehci_hcd :00:02.2: GetStatus port 2 status 001803 POWER sig=j CSC 
> > CONNECT
> > hub 3-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
> > hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
> > ehci_hcd :00:02.2: port 2 high speed
> > ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE 
> > CONNECT
> > usb 3-2: new high speed USB device using ehci_hcd and address 9
> > ehci_hcd :00:02.2: port 2 high speed
> > ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE 
> > CONNECT
> > usb 3-2: default language 0x0409
> > usb 3-2: uevent
> > usb 3-2: usb_probe_device
> > usb 3-2: configuration #1 chosen from 1 choice
> > usb 3-2: adding 3-2:1.0 (config #1, interface 0)
> > usb 3-2:1.0: uevent
> > libusual 3-2:1.0: usb_probe_interface
> > libusual 3-2:1.0: usb_probe_interface - got id
> > usb-storage 3-2:1.0: usb_probe_interface
> > usb-storage 3-2:1.0: usb_probe_interface - got id
> > scsi4 : SCSI emulation for USB Mass Storage devices
> > drivers/usb/core/inode.c: creating file '009'
> > usb 3-2: New USB device found, idVendor=05dc, idProduct=a400
> > usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > usb 3-2: Product: JUMPDRIVE
> > usb 3-2: Manufacturer: LEXAR MEDIA
> > usb 3-2: SerialNumber: 0A4EEC05201219080904
> > usb-storage: device found at 9
> > usb-storage: waiting for device to settle before scanning
> > usb-storage: device scan complete
> > scsi 4:0:0:0: Direct-Access LEXARJUMPDRIVE1000 PQ: 0 ANSI: 
> > 0 CCS
> > sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB)
> > sd 4:0:0:0: [sdg] Write Protect is off
> > sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00
> > sd 4:0:0:0: [sdg] Assuming drive cache: write through
> > sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB)
> > sd 4:0:0:0: [sdg] Write Protect is off
> > sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00
> > sd 4:0:0:0: [sdg] Assuming drive cache: write through
> >  sdg: sdg1
> > sd 4:0:0:0: [sdg] Attached SCSI removable disk
> > sd 4:0:0:0: Attached scsi generic sg7 type 0
> > sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00
> > end_request: I/O error, dev sdg, sector 3984
> 
> Yes, this is breakage in the scsi tree.  I believe that the offending patch
> has been found and I have a nasty fix somewhere in my inbox - it involves
> reverting a patch which doesn't revert properly.  I haven't got onto
> looking at it yet, sorry.

Zan, check this thread http://marc.info/?t=11968982411&r=1&w=2
for unholy details.
--
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: soft lockup - CPU#1 stuck for 15s! [swapper:0]

[Parag Warudkar]

On Dec 7, 2007 6:12 PM, Pallipadi, Venkatesh
<[EMAIL PROTECTED]> wrote:

> Looks like tick_broadcast_lock did not get freed in some path.
> You do not see this when you CPU_IDLE is not configured?
>
> Thanks,
> Venki
>

No, I did not see this prior to enabling CPU_IDLE.

All previous kernels without CPU_IDLE also had soft lockup detection enabled.

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

Re: [PATCH 2/2] cxgb3 - Parity initialization for T3C adapters

[Jeff Garzik]

Divy Le Ray wrote:

Jeff Garzik wrote:

Divy Le Ray wrote:

From: Divy Le Ray <[EMAIL PROTECTED]>

Add parity initialization for T3C adapters.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/adapter.h   |1 
 drivers/net/cxgb3/cxgb3_main.c|   82 

 drivers/net/cxgb3/cxgb3_offload.c |   15 ++
 drivers/net/cxgb3/regs.h  |  248 
+

 drivers/net/cxgb3/sge.c   |   24 +++-
 drivers/net/cxgb3/t3_hw.c |  131 +---
 6 files changed, 472 insertions(+), 29 deletions(-)


dropped patches 2-3, did not apply




Hi Jeff,

I noticed that you applied the first one of this 3 patches series to the 
#upstream-fixes branch.
These patches are intended to the #upstream (2.6.25) branch, as they are 
built on top of the
last 10 patches committed - 9 from me, and the white space clean up 
(thanks!).

May be this is the reason why they did not apply.


Ah... you need to tell me these things.  I looked for a kernel version 
in your messages but did not see one.


Does the patch #1 need to be reverted for 2.6.24?


On this topic, I have a question: how do I get to see all the netdev-2.6 
branches ?
After cloning a free  netdev-2.6 tree, 'git branch' shows only the 
master branch:


bash-3.1$ git --version
git version 1.5.3.rc4.29.g74276-dirty
-bash-3.1$ stg clone 
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
netdev-2.6-fresh
Cloning 
"git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git" 
into "netdev-2.6-fresh"...

Initialized empty Git repository in /opt/sources/netdev-2.6-fresh/.git/
remote: Generating pack...
remote: Counting objects: 620879
Done counting 633562 objects.
remote: Deltifying 633562 objects...
remote:  100% (633562/633562) done
Indexing 633562 objects...
remote: Total 633562 (delta 517968), reused 594305 (delta 478716)
100% (633562/633562) done
Resolving 517968 deltas...
100% (517968/517968) done
Checking 23058 files out...
100% (23058/23058) done
done
-bash-3.1$ cd netdev-2.6-fresh/
-bash-3.1$ git branch
* master


git fetch -f $NETDEV_URL upstream:upstream

copies the latest upstream branch from netdev-2.6.git, and stores it as 
your local upstream branch.


You may do the same for #upstream-fixes too.

Jeff



--
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: new card to me?

[Parag Warudkar]

Gene Heskett  gmail.com> writes:

> 
> Greetings;
> 
> Is this drive interface card supported by the current linux kernel?
> 
> Masscool XWT-RC018, as seen on tigerdirect's site:
> 
>

> 
> Thank you.
> 

The site says it is based on ALi M5283 and this[1] SATA support status page
(Revised Feb 27 2007) says it is supported and the driver is production quality.
sata_uli is the driver.

This [2] review over at Newegg says it works with Linux.

More over the changelogs for sata_uli.c do not indicate they removed support for
it and Google says people found and fixed bugs with that drive [3] - so it would
be a safe bet to say it should be supported with current kernels.

[1] http://linuxmafia.com/faq/Hardware/sata.html
[2] http://www.newegg.com/Product/Product.aspx?Item=N82E16815280001&Tpk=RC018
[3] http://bugzilla.kernel.org/show_bug.cgi?id=7590

[ I went through this recently when I had to buy a SATA card - I got one with a
Silicon Image chip for no particular reason ]

HTH
Parag

--
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.24-rc3-git4 NFS crossmnt regression

[Rafael J. Wysocki]

On Saturday, 8 of December 2007, Andrew Morton wrote:
> On Fri, 07 Dec 2007 17:51:58 -0500
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
> 
> > 
> > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > > On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote:
> > > ...
> > > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > > spots and check for other regressions.
> > > 
> > > Hmm, I installed a new kernel built from the same sources on the NFS
> > > server. And now I don't see anything at all in the crossmnt dirs.
> > > 
> > > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > > 
> > > Are there any other pending fixes?
> > > 
> > > Shane
> > 
> > You've probably fallen afoul of 
> > 
> >http://bugzilla.kernel.org/show_bug.cgi?id=9504
> > 
> 
> Yeah.
> 
> I have a tentative fix below but I can't seem to get Eric and Denis to get
> a suitable fix nailed down.  It's urgent!

Well, how about asking Linus to revert commit
2b1e300a9dfc3196ccddf6f1d74b91b7af55e416 altogether and starting over again?

It apparently causes more trouble than the issue it was supposed to fix.

I've already reopened http://bugzilla.kernel.org/show_bug.cgi?id=9411 and I'll
regard it as unfixed from now on.
--
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.24-rc4-mm1 and Very Slow PCMCIA Compact Flash

[Andrew Morton]

On Fri, 07 Dec 2007 23:09:43 +
Zan Lynx <[EMAIL PROTECTED]> wrote:

> 
> On Fri, 2007-12-07 at 15:02 -0800, Andrew Morton wrote:
> > On Fri, 07 Dec 2007 20:38:24 +
> > Zan Lynx <[EMAIL PROTECTED]> wrote:
> > 
> > > While I'm reporting problems I'll get this one out there.
> > > 
> > > I normally use a USB-2 memory card reader but I also have a PCMCIA
> > > CompactFlash adapter that I use occasionally.  During the MM series
> > > kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all.  I
> > > don't know about vanilla since I don't run that.
> > > 
> > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I
> > > only get read rates of 1.6 MB/s.  When it used to work in 2.6.20 I got
> > > at least 16 MB/s.  The card itself is capable of 30+ in the USB-2
> > > reader.
> > >
> 
> > Are we talking about this?
> [cut]
> > > It might be that it auto-configures for PIO-0.  I have no idea why it
> > > does that.
> > > 
> > > Another interesting thing is that doing a dd to or from the card brings
> > > the rest of the system to a nearly complete halt.  Interrupt problem?
> > 
> > Where are you seeing the evidence that it autoconfigures for PIO-0?
> 
> No, this:
> pccard: PCMCIA card inserted into slot 0
> cs: memory probe 0x5000-0x57ff: excluding 0x5000-0x57ff
> cs: memory probe 0xe010-0xe17f: excluding 0xe010-0xe026 
> 0xe03e-0xe082 0xe0b1-0xe10c
> pcmcia: registering new device pcmcia0.0
> scsi2 : pata_pcmcia
> ata3: PATA max PIO0 cmd 0x3100 ctl 0x310e irq 19
> ata3.00: CFA: LEXAR ATA FLASH, V2.00, max PIO6
> ata3.00: 8018640 sectors, multi 0: LBA 
> ata3.00: configured for PIO0
> ata3.00: configured for PIO0
> ata3: EH complete
> isa bounce pool size: 16 pages
> scsi 2:0:0:0: Direct-Access ATA  LEXAR ATA FLASH  V2.0 PQ: 0 ANSI: 5
> sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB)
> sd 2:0:0:0: [sdb] Write Protect is off
> sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support 
> DPO or FUA
> sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB)
> sd 2:0:0:0: [sdb] Write Protect is off
> sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support 
> DPO or FUA sdb: sdb1
> sd 2:0:0:0: [sdb] Attached SCSI removable disk
> 
> Specifically:
> ata3.00: configured for PIO0
> ata3.00: configured for PIO0

Oh, OK.  Hopefully the ata guys can help out with this.

I don't know if it actually strictly a regression?  Did libata ever support
that device in any earlier kernels?

Alan will be non-respnosive for a few weeks.




Maybe pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards.patch?

Could you try a `patch -R' of the below?


From: Alan Cox <[EMAIL PROTECTED]>

Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 drivers/ata/pata_pcmcia.c |   31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff -puN 
drivers/ata/pata_pcmcia.c~pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards
 drivers/ata/pata_pcmcia.c
--- 
a/drivers/ata/pata_pcmcia.c~pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards
+++ a/drivers/ata/pata_pcmcia.c
@@ -42,7 +42,7 @@
 
 
 #define DRV_NAME "pata_pcmcia"
-#define DRV_VERSION "0.3.2"
+#define DRV_VERSION "0.3.3"
 
 /*
  * Private data structure to glue stuff together
@@ -198,7 +198,6 @@ do { last_fn = (fn); if ((last_ret = (re
 /**
  * pcmcia_init_one -   attach a PCMCIA interface
  * @pdev: pcmcia device
- * @ops: operations for this device
  *
  * Register a PCMCIA IDE interface. Such interfaces are PIO 0 and
  * shared IRQ.
@@ -217,9 +216,10 @@ static int pcmcia_init_one(struct pcmcia
cistpl_cftable_entry_t dflt;
} *stk = NULL;
cistpl_cftable_entry_t *cfg;
-   int pass, last_ret = 0, last_fn = 0, is_kme = 0, ret = -ENOMEM;
+   int pass, last_ret = 0, last_fn = 0, is_kme = 0, ret = -ENOMEM, p;
unsigned long io_base, ctl_base;
void __iomem *io_addr, *ctl_addr;
+   int n_ports = 1;
 
struct ata_port_operations *ops = &pcmcia_port_ops;
 
@@ -348,7 +348,7 @@ next_entry:
/* FIXME: Could be more ports at base + 0x10 but we only deal with
   one right now */
if (pdev->io.NumPorts1 >= 0x20)
-   printk(KERN_WARNING DRV_NAME ": second channel not yet 
supported.\n");
+   n_ports = 2;
 
if (pdev->manf_id == 0x0097 && pdev->card_id == 0x1620)
ops = &pcmcia_8bit_port_ops;
@@ -357,20 +357,23 @@ next_entry:
 *  sane.
 */
ret = -ENOMEM;
-   host = ata_host_alloc(&pdev->dev, 1);
+   host = ata_host_alloc(&pdev->dev, n_ports);
if (!host)
goto failed;
-   ap = host->ports[0];
 
-   ap->ops = ops;
-   ap->pio_mask = 1;  

Re: question about sata-error on boot.

[Tejun Heo]

Hemmann, Volker Armin wrote:
> this is gone with 2.6.22.13 an 2.6.23.9:

Thanks for letting us know.  Probably CLO related problem which got
updated recently.

-- 
tejun
--
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: BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]

[Andrew Morton]

On Fri, 7 Dec 2007 17:53:47 -0500
"Parag Warudkar" <[EMAIL PROTECTED]> wrote:

> Got this on today's git (2.6.24-rc4) while compiling  stuff - Looks
> like it is related to CpuIdle stuff.
> I chose CONFIG_CPU_IDLE for the first time so I don't know when this
> was introduced.
> 
> This is on x86_32, SMP.
> 
> BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
> 
> Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3)
> EIP: 0060:[] EFLAGS: 0202 CPU: 1
> EIP is at _spin_lock_irqsave+0x16/0x27
> EAX: c06b4110 EBX: 0001 ECX: f7873808 EDX: 0293
> ESI: 0005 EDI: f7873808 EBP:  ESP: f7829f10
>  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
> CR0: 8005003b CR2: 004f5960 CR3: 372c5000 CR4: 06d0
> DR0:  DR1:  DR2:  DR3: 
> DR6: 0ff0 DR7: 0400
>  [] tick_broadcast_oneshot_control+0x10/0xda
>  [] tick_notify+0x1d4/0x2eb
>  [] get_next_timer_interrupt+0x143/0x1b4
>  [] notifier_call_chain+0x2a/0x47
>  [] raw_notifier_call_chain+0x17/0x1a
>  [] clockevents_notify+0x19/0x4f
>  [] acpi_idle_enter_simple+0x183/0x1d0
>  [] cpuidle_idle_call+0x53/0x78
>  [] cpuidle_idle_call+0x0/0x78
>  [] cpu_idle+0x97/0xb8

OK, thanks.  Another one for the regression list, please.
--
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.24-rc3-git4 NFS crossmnt regression

[Andrew Morton]

On Fri, 07 Dec 2007 17:51:58 -0500
Trond Myklebust <[EMAIL PROTECTED]> wrote:

> 
> On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> > On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote:
> > ...
> > > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > > spots and check for other regressions.
> > 
> > Hmm, I installed a new kernel built from the same sources on the NFS
> > server. And now I don't see anything at all in the crossmnt dirs.
> > 
> > ls /dirA/dirB/dirC  --> zero output (empty dir)
> > 
> > Are there any other pending fixes?
> > 
> > Shane
> 
> You've probably fallen afoul of 
> 
>http://bugzilla.kernel.org/show_bug.cgi?id=9504
> 

Yeah.

I have a tentative fix below but I can't seem to get Eric and Denis to get
a suitable fix nailed down.  It's urgent!



From: "Denis V. Lunev" <[EMAIL PROTECTED]>

/proc/sys/fs/binfmt_misc dentry disappeared during d_revalidate. 
d_revalidate only dentries from shadowed one and below. 
http://bugzilla.kernel.org/show_bug.cgi?id=9504

Cc: Eric W. Biederman <[EMAIL PROTECTED]>
Cc: Marcus Better <[EMAIL PROTECTED]>
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
Cc: Marcus Better <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 fs/proc/generic.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff -puN fs/proc/generic.c~lost-content-of-proc-sys-fs-binfmt_misc 
fs/proc/generic.c
--- a/fs/proc/generic.c~lost-content-of-proc-sys-fs-binfmt_misc
+++ a/fs/proc/generic.c
@@ -380,12 +380,17 @@ static int proc_revalidate_dentry(struct
return 0;
 }
 
-static struct dentry_operations proc_dentry_operations =
+static struct dentry_operations proc_dentry_shadow_operations =
 {
.d_delete   = proc_delete_dentry,
.d_revalidate   = proc_revalidate_dentry,
 };
 
+static struct dentry_operations proc_dentry_operations =
+{
+   .d_delete   = proc_delete_dentry,
+};
+
 /*
  * Don't create negative dentries here, return -ENOENT by hand
  * instead.
@@ -394,6 +399,7 @@ struct dentry *proc_lookup(struct inode 
 {
struct inode *inode = NULL;
struct proc_dir_entry * de;
+   int use_shadow = 0;
int error = -ENOENT;
 
lock_kernel();
@@ -406,8 +412,10 @@ struct dentry *proc_lookup(struct inode 
if (!memcmp(dentry->d_name.name, de->name, 
de->namelen)) {
unsigned int ino;
 
-   if (de->shadow_proc)
+   if (de->shadow_proc) {
de = de->shadow_proc(current, de);
+   use_shadow = 1;
+   }
ino = de->low_ino;
de_get(de);
spin_unlock(&proc_subdir_lock);
@@ -423,6 +431,8 @@ struct dentry *proc_lookup(struct inode 
 
if (inode) {
dentry->d_op = &proc_dentry_operations;
+   dentry->d_op = use_shadow ?
+   &proc_dentry_shadow_operations : dentry->d_parent->d_op;
d_add(dentry, inode);
return NULL;
}
_

--
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: soft lockup - CPU#1 stuck for 15s! [swapper:0]

[Pallipadi, Venkatesh]

 

>-Original Message-
>From: Parag Warudkar [mailto:[EMAIL PROTECTED] 
>Sent: Friday, December 07, 2007 2:54 PM
>To: LKML
>Cc: Andrew Morton; Pallipadi, Venkatesh; Linus Torvalds
>Subject: BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
>
>Got this on today's git (2.6.24-rc4) while compiling  stuff - Looks
>like it is related to CpuIdle stuff.
>I chose CONFIG_CPU_IDLE for the first time so I don't know when this
>was introduced.
>
>This is on x86_32, SMP.
>
>BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
>
>Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3)
>EIP: 0060:[] EFLAGS: 0202 CPU: 1
>EIP is at _spin_lock_irqsave+0x16/0x27
>EAX: c06b4110 EBX: 0001 ECX: f7873808 EDX: 0293
>ESI: 0005 EDI: f7873808 EBP:  ESP: f7829f10
> DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
>CR0: 8005003b CR2: 004f5960 CR3: 372c5000 CR4: 06d0
>DR0:  DR1:  DR2:  DR3: 
>DR6: 0ff0 DR7: 0400
> [] tick_broadcast_oneshot_control+0x10/0xda
> [] tick_notify+0x1d4/0x2eb
> [] get_next_timer_interrupt+0x143/0x1b4
> [] notifier_call_chain+0x2a/0x47
> [] raw_notifier_call_chain+0x17/0x1a
> [] clockevents_notify+0x19/0x4f
> [] acpi_idle_enter_simple+0x183/0x1d0
> [] cpuidle_idle_call+0x53/0x78
> [] cpuidle_idle_call+0x0/0x78
> [] cpu_idle+0x97/0xb8
>

Looks like tick_broadcast_lock did not get freed in some path.
You do not see this when you CPU_IDLE is not configured? 

Thanks,
Venki
--
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] Fake NUMA emulation for PowerPC

[David Rientjes]

On Sat, 8 Dec 2007, Balbir Singh wrote:

> Yes, they all appear on node 0. We could have tweaks to distribute CPU's
> as well.
> 

You're going to want to distribute the cpu's based on how they match up 
physically with the actual platform that you're running on.  x86_64 does 
this already and it makes fake NUMA more useful because it matches the 
real-life case more often.
--
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.22.14 oops msg with commvault galaxy ?

[Andrew Morton]

On Fri, 7 Dec 2007 14:15:36 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:

> > Help would really be appreciated.
> 
> Let's try the last_sysfs_file (name) patch.
> I've attempted to update it for 2.6.22.14.
> Andrew, does this change in fs/sysfs/file.c look OK?

umm, yup.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/gregkh-driver-sysfs-crash-debugging.patch

should work.
--
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] Fake NUMA emulation for PowerPC

[David Rientjes]

On Sat, 8 Dec 2007, Balbir Singh wrote:

> To be able to test the memory controller under NUMA, I use fake NUMA
> nodes. x86-64 has a similar feature, the code I have here is the
> simplest I could come up with for PowerPC.
> 

Magnus Damm had patches from over a year ago that, I believe, made much of 
the x86_64 fake NUMA code generic so that it could be extended for 
architectures such as i386.  Perhaps he could resurrect those patches if 
there is wider interest in such a tool.
--
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.24-rc4-mm1 and Very Slow PCMCIA Compact Flash

[Zan Lynx]

On Fri, 2007-12-07 at 15:02 -0800, Andrew Morton wrote:
> On Fri, 07 Dec 2007 20:38:24 +
> Zan Lynx <[EMAIL PROTECTED]> wrote:
> 
> > While I'm reporting problems I'll get this one out there.
> > 
> > I normally use a USB-2 memory card reader but I also have a PCMCIA
> > CompactFlash adapter that I use occasionally.  During the MM series
> > kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all.  I
> > don't know about vanilla since I don't run that.
> > 
> > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I
> > only get read rates of 1.6 MB/s.  When it used to work in 2.6.20 I got
> > at least 16 MB/s.  The card itself is capable of 30+ in the USB-2
> > reader.
> >

> Are we talking about this?
[cut]
> > It might be that it auto-configures for PIO-0.  I have no idea why it
> > does that.
> > 
> > Another interesting thing is that doing a dd to or from the card brings
> > the rest of the system to a nearly complete halt.  Interrupt problem?
> 
> Where are you seeing the evidence that it autoconfigures for PIO-0?

No, this:
pccard: PCMCIA card inserted into slot 0
cs: memory probe 0x5000-0x57ff: excluding 0x5000-0x57ff
cs: memory probe 0xe010-0xe17f: excluding 0xe010-0xe026 
0xe03e-0xe082 0xe0b1-0xe10c
pcmcia: registering new device pcmcia0.0
scsi2 : pata_pcmcia
ata3: PATA max PIO0 cmd 0x3100 ctl 0x310e irq 19
ata3.00: CFA: LEXAR ATA FLASH, V2.00, max PIO6
ata3.00: 8018640 sectors, multi 0: LBA 
ata3.00: configured for PIO0
ata3.00: configured for PIO0
ata3: EH complete
isa bounce pool size: 16 pages
scsi 2:0:0:0: Direct-Access ATA  LEXAR ATA FLASH  V2.0 PQ: 0 ANSI: 5
sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support 
DPO or FUA
sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support 
DPO or FUA sdb: sdb1
sd 2:0:0:0: [sdb] Attached SCSI removable disk

Specifically:
ata3.00: configured for PIO0
ata3.00: configured for PIO0
-- 
Zan Lynx <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: programs vanish with 2.6.22+

[Simon Holm Thøgersen]

fre, 07 12 2007 kl. 23:52 +0100, skrev Markus:
> Well, now some windows vanished, but no additional messages were 
> produced by kernel. When somebody could tell what I exactly need to 
> do... would be nice.
> Or a hit, in what direction I should look. Because its really nasty to 
> not being able to use a current kernel.
> 
> I already rebuild the whole system, as suggested by the gentoo-devs, 
> without success.
> 
> I could also try to debug/strace/whatever the apps and wait for it to 
> disappear.
> 
> Just talk to me, I am not able to do this on my own...
> 
If you feel like you are able to tell whether a specific kernel version
is buggy or not, you might want to try to bisect it. See
Documentation/BUG-HUNTING in the sources, and please ask.


Simon Holm Thøgersen

--
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] Fake NUMA emulation for PowerPC

[David Rientjes]

On Fri, 7 Dec 2007, Olof Johansson wrote:

> > Comments are as always welcome!
> 
> Care to explain what this is useful for? (Not saying it's a stupid idea,
> just wondering what the reason for doing it is).
> 

Fake NUMA has always been useful for testing NUMA code without having to 
have a wide range of hardware available to you.  It's a clever tool on 
x86_64 intended for kernel developers that simply makes it easier to test 
code and adds an increased level of robustness to the kernel.  I think 
it's a valuable addition.
--
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.24-rc4-mm1 and excessive block IO errors

[Andrew Morton]

On Fri, 07 Dec 2007 20:44:45 +
Zan Lynx <[EMAIL PROTECTED]> wrote:

> I am not sure if this problem has been addressed already.  I read some
> about the fast-fail issues and this may be related?
> 
> On nearly all my USB block devices, I have been getting zillions of I/O
> errors.  But they aren't real, they don't appear with 2.6.23 kernels.
> 
> I can often read and write data to the device, but these IO errors cause
> error aborts in user space applications in many cases, making it a
> chancy thing to run backup software, for example.
> 
> Here is a bit of dmesg from plugging in a perfectly good USB-2 flash
> drive.
> 
> hub 3-0:1.0: state 7 ports 6 chg  evt 0004
> ehci_hcd :00:02.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
> hub 3-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
> hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
> ehci_hcd :00:02.2: port 2 high speed
> ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
> usb 3-2: new high speed USB device using ehci_hcd and address 9
> ehci_hcd :00:02.2: port 2 high speed
> ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
> usb 3-2: default language 0x0409
> usb 3-2: uevent
> usb 3-2: usb_probe_device
> usb 3-2: configuration #1 chosen from 1 choice
> usb 3-2: adding 3-2:1.0 (config #1, interface 0)
> usb 3-2:1.0: uevent
> libusual 3-2:1.0: usb_probe_interface
> libusual 3-2:1.0: usb_probe_interface - got id
> usb-storage 3-2:1.0: usb_probe_interface
> usb-storage 3-2:1.0: usb_probe_interface - got id
> scsi4 : SCSI emulation for USB Mass Storage devices
> drivers/usb/core/inode.c: creating file '009'
> usb 3-2: New USB device found, idVendor=05dc, idProduct=a400
> usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 3-2: Product: JUMPDRIVE
> usb 3-2: Manufacturer: LEXAR MEDIA
> usb 3-2: SerialNumber: 0A4EEC05201219080904
> usb-storage: device found at 9
> usb-storage: waiting for device to settle before scanning
> usb-storage: device scan complete
> scsi 4:0:0:0: Direct-Access LEXARJUMPDRIVE1000 PQ: 0 ANSI: 0 
> CCS
> sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB)
> sd 4:0:0:0: [sdg] Write Protect is off
> sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00
> sd 4:0:0:0: [sdg] Assuming drive cache: write through
> sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB)
> sd 4:0:0:0: [sdg] Write Protect is off
> sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00
> sd 4:0:0:0: [sdg] Assuming drive cache: write through
>  sdg: sdg1
> sd 4:0:0:0: [sdg] Attached SCSI removable disk
> sd 4:0:0:0: Attached scsi generic sg7 type 0
> sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00
> end_request: I/O error, dev sdg, sector 3984

Yes, this is breakage in the scsi tree.  I believe that the offending patch
has been found and I have a nasty fix somewhere in my inbox - it involves
reverting a patch which doesn't revert properly.  I haven't got onto
looking at it yet, sorry.
--
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.24-rc4-mm1 and Very Slow PCMCIA Compact Flash

[Andrew Morton]

On Fri, 07 Dec 2007 20:38:24 +
Zan Lynx <[EMAIL PROTECTED]> wrote:

> While I'm reporting problems I'll get this one out there.
> 
> I normally use a USB-2 memory card reader but I also have a PCMCIA
> CompactFlash adapter that I use occasionally.  During the MM series
> kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all.  I
> don't know about vanilla since I don't run that.
> 
> Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I
> only get read rates of 1.6 MB/s.  When it used to work in 2.6.20 I got
> at least 16 MB/s.  The card itself is capable of 30+ in the USB-2
> reader.
> 
> It might be that it auto-configures for PIO-0.  I have no idea why it
> does that.
> 
> Another interesting thing is that doing a dd to or from the card brings
> the rest of the system to a nearly complete halt.  Interrupt problem?

Are we talking about this?


Yenta: CardBus bridge found at :02:04.0 [103c:006d]
PCI: Bus 3, cardbus bridge: :02:04.0
  IO window: 3000-30ff
  IO window: 3400-34ff
  PREFETCH window: 5000-53ff
  MEM window: e040-e07f
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket :02:04.0, mfunc 0x0d22, devctl 0x64
Yenta: ISA IRQ mask 0x0cf8, PCI irq 19
Socket status: 3051
Yenta: Raising subordinate bus# of parent bus (#02) from #02 to #06
pcmcia: parent PCI bridge I/O window: 0x3000 - 0x7fff
pcmcia: parent PCI bridge Memory window: 0xe010 - 0xe17f
pcmcia: parent PCI bridge Memory window: 0x5000 - 0x57ff
Yenta: CardBus bridge found at :02:04.1 [103c:006d]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket :02:04.1, mfunc 0x0d22, devctl 0x64
Yenta: ISA IRQ mask 0x0cf8, PCI irq 18
Socket status: 3006
Yenta: Raising subordinate bus# of parent bus (#02) from #06 to #0a
pcmcia: parent PCI bridge I/O window: 0x3000 - 0x7fff
pcmcia: parent PCI bridge Memory window: 0xe010 - 0xe17f
pcmcia: parent PCI bridge Memory window: 0x5000 - 0x57ff
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
cpuidle: using governor ladder
input: AT Translated Set 2 keyboard as 
/devices/platform/i8042/serio0/input/input4
pccard: PCMCIA card inserted into slot 0
cs: memory probe 0x5000-0x57ff: excluding 0x5000-0x57ff
cs: memory probe 0xe010-0xe17f: excluding 0xe010-0xe026 
0xe03e-0xe082 0xe0b1-0xe10c
pcmcia: registering new device pcmcia0.0

> It might be that it auto-configures for PIO-0.  I have no idea why it
> does that.
> 
> Another interesting thing is that doing a dd to or from the card brings
> the rest of the system to a nearly complete halt.  Interrupt problem?

Where are you seeing the evidence that it autoconfigures for PIO-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/

lockdep problem conversion semaphore->mutex (dev->sem)

[Remy Bohmer]

Hello Peter,

> > What specifically is wrong with dev->sem ?
>
> Nothing really, other than that they use semaphores to avoid lockdep :-/
>
> I think I know how to annotate this, after Alan Stern explained all the
> use cases, but I haven't come around to implementing it. Hope to do that
> soonish.

I was looking for an easy semaphore I could convert to a mutex, and I
ran into one that was widely spread and interesting, and which seemed
quite doable at first sight.
So, I started working on it, but was forgotten this discussion, (until
Daniel made me remember it this afternoon). So, I (stupid me ;-) )
tried to convert dev->sem...

After doing the monkey part of the conversion I can boot the kernel
completely on X86 and ARM, and everything works fine, except after
enabling lockdep, lockdep starts complaining...

Is this the problem you were pointing at?
===
Setting up standard PCI resources
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing

=
[ INFO: possible recursive locking detected ]
2.6.24-rc4 #5
-
swapper/1 is trying to acquire lock:
 (&dev->mut){--..}, at: [] __driver_attach+0x2c/0x5f

but task is already holding lock:
 (&dev->mut){--..}, at: [] __driver_attach+0x1d/0x5f

other info that might help us debug this:
1 lock held by swapper/1:
 #0:  (&dev->mut){--..}, at: [] __driver_attach+0x1d/0x5f

stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.24-rc4 #5
 [] __lock_acquire+0x17b/0xb83
 [] trace_hardirqs_on+0x11a/0x13d
 [] lock_acquire+0x5f/0x77
 [] __driver_attach+0x2c/0x5f
 [] mutex_lock_nested+0x105/0x26b
 [] __driver_attach+0x2c/0x5f
 [] __driver_attach+0x2c/0x5f
 [] __driver_attach+0x0/0x5f
 [] __driver_attach+0x2c/0x5f
 [] bus_for_each_dev+0x3a/0x5c
 [] driver_attach+0x16/0x18
 [] __driver_attach+0x0/0x5f
 [] bus_add_driver+0x6d/0x19a
 [] acpi_ec_init+0x33/0x51
 [] kernel_init+0x148/0x2af
 [] kernel_init+0x0/0x2af
 [] kernel_init+0x0/0x2af
 [] kernel_thread_helper+0x7/0x10
 ===
ACPI: PCI Root Bridge [PCI0] (:00)
Force enabled HPET at base address 0xfed0
===

I tried debugging it, and I have not found a recursive mutex locking
so far, only locking of 2 different mutexes in a row prior to this
warning, which IMO should be valid.

What is your opinion?

BTW: I attached my patch for dev->sem as I have it now, that generates
this lockdep warning ( for if you want to look at it yourself also, so
you do not have to do the monkey part yourself anymore ;-)


Kind Regards,

Remy


patch_replace_sem_by_mutex_in_device_h
Description: Binary data

Re: programs vanish with 2.6.22+

[Markus]

Well, now some windows vanished, but no additional messages were 
produced by kernel. When somebody could tell what I exactly need to 
do... would be nice.
Or a hit, in what direction I should look. Because its really nasty to 
not being able to use a current kernel.

I already rebuild the whole system, as suggested by the gentoo-devs, 
without success.

I could also try to debug/strace/whatever the apps and wait for it to 
disappear.

Just talk to me, I am not able to do this on my own...


Markus

> On Fri, 7 Dec 2007, Markus wrote:
> 
> > Hi again!
> > 
> > The memtest ran 14 passes (~10h) without an error.
> > 
> > I now have a 2.6.24-rc4 with some debug-options turned on, waiting 
for 
> > something to happen... can I just leave it untill a window 
disappears 
> > or do I need to manually enable something or run some user-space 
app?!
> 
> It depends - different options have it differently. Most simple ones 
are 
> just compile-time, so, you don't have to enable them. Look in "help" 
for 
> respective debug-options.
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski
> 


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

Re: x86_64 dynticks not working prev: cpuidle, dynticks compatible or no?

[Ed Sweetman]

System is idle now, previously it was doing something i couldn't halt at 
the time.  
I'm looking at "Local timer interrupts" in the "Loc:" section of 
/proc/interrupts.
Across 1 second while the system is pretty much idle, i still get 300 
interrupts. My HZ variable is set to 300 in the kernel config, so this 
is expected but I was under the assumption that dynticks/tickless being 
compiled in would cause that to be much lower.


Am I reading the wrong section of /proc/interrupts  to verify if 
dynticks is working or not? Again, i see no difference in cpu temp at all.


In case it helps, this is an athlon64 x2 with apic functioning and both 
cores active in 64bit mode. dmesg is below. 


not related :
Some additional notes:  it87 is my lm_sensor, it doesn't work in this 
kernel, yet it did in 2.6.22.  Perhaps enabling high precision timers 
changed something in acpi land.


I enabled tcp dma offloading in this kernel, i get debugging output 
related to it, error is at the last line.  No corruption or otherwise 
bad behavior.   Transferring via cifs at 9.7MB/sec "incoming" took about 
15% of one cpu...  I never bothered to check if that is the norm but i 
suspect i'll be removing that feature as it seems to not play nice with 
the kernel.




kernel: klogd 1.5.0#1, log source = /proc/kmsg started.
) (gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)) #1 SMP 
PREEMPT Wed Dec 5 21:49:34 EST 2007

kernel: Command line: root=/dev/sda1 ro console=tty0 libata.atapi_enabled=1
kernel: BIOS-provided physical RAM map:
kernel:  BIOS-e820:  - 0009f400 (usable)
kernel:  BIOS-e820: 0009f400 - 000a (reserved)
kernel:  BIOS-e820: 000f - 0010 (reserved)
kernel:  BIOS-e820: 0010 - 7fff (usable)
kernel:  BIOS-e820: 7fff - 7fff3000 (ACPI NVS)
kernel:  BIOS-e820: 7fff3000 - 8000 (ACPI data)
kernel:  BIOS-e820: e000 - f000 (reserved)
kernel:  BIOS-e820: fec0 - 0001 (reserved)
kernel: end_pfn_map = 1048576
kernel: DMI 2.3 present.
kernel: ACPI: RSDP 000F7580, 0014 (r0 Nvidia)
kernel: ACPI: RSDT 7FFF3040, 0034 (r1 Nvidia AWRDACPI 42302E31 
AWRD0)
kernel: ACPI: FACP 7FFF30C0, 0074 (r1 Nvidia AWRDACPI 42302E31 
AWRD0)
kernel: ACPI: DSDT 7FFF3180, 65F2 (r1 NVIDIA AWRDACPI 1000 MSFT  
10E)

kernel: ACPI: FACS 7FFF, 0040
kernel: ACPI: SSDT 7FFF9880, 0188 (r1 PTLTD  POWERNOW1  
LTP1)
kernel: ACPI: MCFG 7FFF9A80, 003C (r1 Nvidia AWRDACPI 42302E31 
AWRD0)
kernel: ACPI: APIC 7FFF97C0, 007C (r1 Nvidia AWRDACPI 42302E31 
AWRD0)

kernel: Zone PFN ranges:
kernel:   DMA 0 -> 4096
kernel:   DMA324096 ->  1048576
kernel:   Normal1048576 ->  1048576
kernel: Movable zone start PFN for each node
kernel: early_node_map[2] active PFN ranges
kernel: 0:0 ->  159
kernel: 0:  256 ->   524272
kernel: Nvidia board detected. Ignoring ACPI timer override.
kernel: If you got timer trouble try acpi_use_timer_override
kernel: ACPI: PM-Timer IO Port: 0x4008
kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
kernel: Processor #0 (Bootup-CPU)
kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
kernel: Processor #1
kernel: ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
kernel: ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
kernel: ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
kernel: IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
kernel: ACPI: BIOS IRQ0 pin2 override ignored.
kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
kernel: Setting APIC routing to flat
kernel: Using ACPI (MADT) for SMP configuration information
kernel: Allocating PCI resources starting at 8800 (gap: 
8000:6000)

kernel: SMP: Allowing 2 CPUs, 0 hotplug CPUs
kernel: PERCPU: Allocating 32696 bytes of per cpu data
kernel: Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 515935
kernel: Kernel command line: root=/dev/sda1 ro console=tty0 
libata.atapi_enabled=1

kernel: Initializing CPU#0
kernel: PID hash table entries: 4096 (order: 12, 32768 bytes)
kernel: TSC calibrated against PM_TIMER
kernel: Marking TSC unstable due to TSCs unsynchronized
kernel: time.c: Detected 2010.305 MHz processor.
kernel: Console: colour VGA+ 80x25
kernel: console [tty0] enabled
kernel: Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
kernel: Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
kernel: Checking aperture...
kernel: CPU 0: aperture @ 864000 size 32 MB
kernel: No AGP bridge found
kernel: Memory: 2059736k/2097088k available (2695k kernel code, 36256k 
reserved, 1069k data, 204k init)
kernel: 

BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]

[Parag Warudkar]

Got this on today's git (2.6.24-rc4) while compiling  stuff - Looks
like it is related to CpuIdle stuff.
I chose CONFIG_CPU_IDLE for the first time so I don't know when this
was introduced.

This is on x86_32, SMP.

BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]

Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3)
EIP: 0060:[] EFLAGS: 0202 CPU: 1
EIP is at _spin_lock_irqsave+0x16/0x27
EAX: c06b4110 EBX: 0001 ECX: f7873808 EDX: 0293
ESI: 0005 EDI: f7873808 EBP:  ESP: f7829f10
 DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
CR0: 8005003b CR2: 004f5960 CR3: 372c5000 CR4: 06d0
DR0:  DR1:  DR2:  DR3: 
DR6: 0ff0 DR7: 0400
 [] tick_broadcast_oneshot_control+0x10/0xda
 [] tick_notify+0x1d4/0x2eb
 [] get_next_timer_interrupt+0x143/0x1b4
 [] notifier_call_chain+0x2a/0x47
 [] raw_notifier_call_chain+0x17/0x1a
 [] clockevents_notify+0x19/0x4f
 [] acpi_idle_enter_simple+0x183/0x1d0
 [] cpuidle_idle_call+0x53/0x78
 [] cpuidle_idle_call+0x0/0x78
 [] cpu_idle+0x97/0xb8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] cxgb3 - Parity initialization for T3C adapters

[Divy Le Ray]

Jeff Garzik wrote:

Divy Le Ray wrote:

From: Divy Le Ray <[EMAIL PROTECTED]>

Add parity initialization for T3C adapters.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/adapter.h   |1 
 drivers/net/cxgb3/cxgb3_main.c|   82 

 drivers/net/cxgb3/cxgb3_offload.c |   15 ++
 drivers/net/cxgb3/regs.h  |  248 
+

 drivers/net/cxgb3/sge.c   |   24 +++-
 drivers/net/cxgb3/t3_hw.c |  131 +---
 6 files changed, 472 insertions(+), 29 deletions(-)


dropped patches 2-3, did not apply




Hi Jeff,

I noticed that you applied the first one of this 3 patches series to the 
#upstream-fixes branch.
These patches are intended to the #upstream (2.6.25) branch, as they are 
built on top of the
last 10 patches committed - 9 from me, and the white space clean up 
(thanks!).

May be this is the reason why they did not apply.

On this topic, I have a question: how do I get to see all the netdev-2.6 
branches ?
After cloning a free  netdev-2.6 tree, 'git branch' shows only the 
master branch:


bash-3.1$ git --version
git version 1.5.3.rc4.29.g74276-dirty
-bash-3.1$ stg clone 
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
netdev-2.6-fresh
Cloning 
"git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git" 
into "netdev-2.6-fresh"...

Initialized empty Git repository in /opt/sources/netdev-2.6-fresh/.git/
remote: Generating pack...
remote: Counting objects: 620879
Done counting 633562 objects.
remote: Deltifying 633562 objects...
remote:  100% (633562/633562) done
Indexing 633562 objects...
remote: Total 633562 (delta 517968), reused 594305 (delta 478716)
100% (633562/633562) done
Resolving 517968 deltas...
100% (517968/517968) done
Checking 23058 files out...
100% (23058/23058) done
done
-bash-3.1$ cd netdev-2.6-fresh/
-bash-3.1$ git branch
* master

Cheers,
Divy


--
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.24-rc3-git4 NFS crossmnt regression

[Trond Myklebust]

On Fri, 2007-12-07 at 14:39 -0500, Shane wrote:
> On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote:
> ...
> > Confirmed working in rc4-git5.  I'll deploy this kernel in a few more
> > spots and check for other regressions.
> 
> Hmm, I installed a new kernel built from the same sources on the NFS
> server. And now I don't see anything at all in the crossmnt dirs.
> 
> ls /dirA/dirB/dirC  --> zero output (empty dir)
> 
> Are there any other pending fixes?
> 
> Shane

You've probably fallen afoul of 

   http://bugzilla.kernel.org/show_bug.cgi?id=9504

Cheers
  Trond

--
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.24-rc3-git4 NFS crossmnt regression

[Trond Myklebust]

On Fri, 2007-12-07 at 14:33 -0800, Andrew Morton wrote:
> On Fri, 07 Dec 2007 13:46:19 -0500
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
> 
> > 
> > On Fri, 2007-12-07 at 13:14 -0500, Shane wrote:
> > > On Dec 7, 2007 7:02 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > ...
> > > > > 2.6.24-rc3-git1 is last known good kernel. The problem also exists
> > > > > with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
> > > > > is unchanged.
> > > >
> > > > hm, there have been no nfs changes since 2.6.24-rc4.
> > > 
> > > Ok, but the problem seems to have appeared before 2.6.24-rc4.
> > > 
> > > > > It is easily reproducible here, hopefully for the person who
> > > > > knows how to debug it too :)
> > > > >
> > > >
> > > > I guess a full set of the commands which you typed to reproduce this 
> > > > would
> > > > help.
> > > 
> > > Server is 2.6.23-rc9 and is exporting:
> > > 
> > > /dirA/dirB
> > > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure,crossmnt)
> > > /dirA/dirB/dirC
> > > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> > > /dirA/dirB/dirD
> > > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> > > 
> > > The NFS client (Core2 SMP) 2.6.24-rc3-git4:
> > > 
> > > NFS-server:/dirA/dirB /dirA/dirBnfs
> > > auto,rsize=16384,wsize=16384,hard,intr,users,exec,nfsvers=3,tcp,nolock,actimeo=0
> > > 
> > > Then on the client when the new kernel has booted:
> > > 
> > > ls /dirA/dirB  --> normal listing
> > > ls /dirA/dirB/dirC   -->  Stale NFS file handle
> > > ls /dirA/dirB/dirD   -->  Stale NFS file handle
> > > 
> > > I will do a few more builds/boots and check -rc3-git2 and -rc3-git3.
> > 
> > This problem has already been reported. The fix (which I'm planning on
> > sending to Linus soon) is appended.
> > 
> 
> That patch isn't in git://git.linux-nfs.org/pub/linux/nfs-2.6.git.  In fact
> that tree is empty.
> 
> Has something gone wrong here?

I'm expecting an updated fix for another bug. Once that is done, I'll
merge those 2 to Linus, then start queueing up the 2.6.25 merge tree...

Trond

--
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: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

[Bob Tracy]

Kay Sievers wrote:
> Yeah, that looks all fine.
> 
> What distro is that, and what's the udev version?

Mine is Debian Etch, normally with the latest released or -rcX kernel
from kernel.org.  Updates current as of about 18 hours ago.  Udev
package version is 0.105-4.  The RELEASE-NOTES file in /usr/share/doc/udev
says "udev 105".

> You are booting your kernel with an initramfs?

Not in my case: everything I need at boot time is built-in.

> Is the udev daemon (still) running while it fails?
> 
> If you run /sbin/udevtrigger, do the nodes appear?

I can answer the above later when I'm back in front of the machine, but
even in the "not good" case, I still see the following messages from
the /etc/rcS.d/S03udev file:

Starting the hotplug events dispatcher udevd.
Synthesizing the initial hotplug events.

This is where udevtrigger gets called, followed by the load_input_modules
and create_dev_makedev functions, then...

Waiting for /dev to be fully populated.

which is where udevsettle gets called.

None of the above appear to be exiting abnormally for the bad case, but
I'll definitely take a closer look at what MAKEDEV (/dev/MAKEDEV -->
/sbin/MAKEDEV) is doing.  In particular, Debian MAKEDEV is looking at
/proc/devices to decide what to do, so maybe "cat /proc/devices" would
be useful to look at for the broken case.

-- 

Bob Tracy  |  "They couldn't hit an elephant at this dist- "
[EMAIL PROTECTED]   |   - Last words of Union General John Sedgwick,
   |  Battle of Spotsylvania Court House, U.S. Civil War

--
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] Fake NUMA emulation for PowerPC (Take 2)

[Balbir Singh]

Changelog

1. Get rid of the constant 5 (based on comments from
[EMAIL PROTECTED])
2. Implement suggestions from Olof Johannson
3. Check if cmdline is NULL in fake_numa_create_new_node()

Tested with additional parameters from Olof

numa=debug,fake=
numa=foo,fake=bar


Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
NUMA nodes can be specified using the following command line option

numa=fake=

node range is of the format ,,...

Each of the rangeX parameters is passed using memparse(). I find the patch
useful for fake NUMA emulation on my simple PowerPC machine. I've tested it
on a non-numa box with the following arguments

numa=fake=1G
numa=fake=1G,2G
name=fake=1G,512M,2G
numa=fake=1500M,2800M mem=3500M
numa=fake=1G mem=512M
numa=fake=1G mem=1G

This patch applies on top of 2.6.24-rc4.

All though I've tried my best to handle some of the architecture specific
details of PowerPC, I might have overlooked something obvious, like the usage
of an API or some architecture tweaks. The patch depends on CONFIG_NUMA and
I decided against creating a separate config option for fake NUMA to keep
the code simple.

Comments are as always welcome!

Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---

 arch/powerpc/mm/numa.c |   59 -
 1 file changed, 54 insertions(+), 5 deletions(-)

diff -puN arch/powerpc/mm/numa.c~ppc-fake-numa-easy arch/powerpc/mm/numa.c
--- linux-2.6.24-rc4-mm1/arch/powerpc/mm/numa.c~ppc-fake-numa-easy  
2007-12-07 21:25:55.0 +0530
+++ linux-2.6.24-rc4-mm1-balbir/arch/powerpc/mm/numa.c  2007-12-08 
03:19:46.0 +0530
@@ -24,6 +24,8 @@
 
 static int numa_enabled = 1;
 
+static char *cmdline __initdata;
+
 static int numa_debug;
 #define dbg(args...) if (numa_debug) { printk(KERN_INFO args); }
 
@@ -39,6 +41,43 @@ static bootmem_data_t __initdata plat_no
 static int min_common_depth;
 static int n_mem_addr_cells, n_mem_size_cells;
 
+static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
+   unsigned int *nid)
+{
+   unsigned long long mem;
+   char *p = cmdline;
+   static unsigned int fake_nid = 0;
+   static unsigned long long curr_boundary = 0;
+
+   *nid = fake_nid;
+   if (!p)
+   return 0;
+
+   mem = memparse(p, &p);
+   if (!mem)
+   return 0;
+
+   if (mem < curr_boundary)
+   return 0;
+
+   curr_boundary = mem;
+
+   if ((end_pfn << PAGE_SHIFT) > mem) {
+   /*
+* Skip commas and spaces
+*/
+   while (*p == ',' || *p == ' ' || *p == '\t')
+   p++;
+
+   cmdline = p;
+   fake_nid++;
+   *nid = fake_nid;
+   dbg("created new fake_node with id %d\n", fake_nid);
+   return 1;
+   }
+   return 0;
+}
+
 static void __cpuinit map_cpu_to_node(int cpu, int node)
 {
numa_cpu_lookup_table[cpu] = node;
@@ -344,12 +383,14 @@ static void __init parse_drconf_memory(s
if (nid == 0x || nid >= MAX_NUMNODES)
nid = default_nid;
}
-   node_set_online(nid);
 
size = numa_enforce_memory_limit(start, lmb_size);
if (!size)
continue;
 
+   fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
+   node_set_online(nid);
+
add_active_range(nid, start >> PAGE_SHIFT,
 (start >> PAGE_SHIFT) + (size >> PAGE_SHIFT));
}
@@ -429,7 +470,6 @@ new_range:
nid = of_node_to_nid_single(memory);
if (nid < 0)
nid = default_nid;
-   node_set_online(nid);
 
if (!(size = numa_enforce_memory_limit(start, size))) {
if (--ranges)
@@ -438,6 +478,9 @@ new_range:
continue;
}
 
+   fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
+   node_set_online(nid);
+
add_active_range(nid, start >> PAGE_SHIFT,
(start >> PAGE_SHIFT) + (size >> PAGE_SHIFT));
 
@@ -461,7 +504,7 @@ static void __init setup_nonnuma(void)
unsigned long top_of_ram = lmb_end_of_DRAM();
unsigned long total_ram = lmb_phys_mem_size();
unsigned long start_pfn, end_pfn;
-   unsigned int i;
+   unsigned int i, nid = 0;
 
printk(KERN_DEBUG "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
   top_of_ram, total_ram);
@@ -471,9 +514,11 @@ static void __init setup_nonnuma(void)
for (i = 0; i < lmb.memory.cnt; ++i) {
start_pfn = lmb.memory.region[i].base >> PAGE_SHIFT;
end_pfn = start_pfn + lmb_size_pages(&lmb.memory, i);
-   

Re: [PATCH] SCSI: make pcmcia directory use obj-y|m instead of subdir-y|m

[Tejun Heo]

Sam Ravnborg wrote:
> On Fri, Dec 07, 2007 at 10:36:23PM +0900, Tejun Heo wrote:
>> subdir-y|m isn't supposed to contain modules or built-in components.
>> Change subdir-$(CONFIG_PCMCIA) to obj-$(CONFIG_PCMCIA).
>>
>> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>> Cc: Sam Ravnborg <[EMAIL PROTECTED]>
>> Cc: James Bottomley <[EMAIL PROTECTED]>
> Ack-by: Sam Ravnborg <[EMAIL PROTECTED]>

Thanks.  I guess this should go through SCSI tree.  James, can you
please forward this upstream?

-- 
tejun
--
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.24-rc3-git4 NFS crossmnt regression

[Andrew Morton]

On Fri, 07 Dec 2007 13:46:19 -0500
Trond Myklebust <[EMAIL PROTECTED]> wrote:

> 
> On Fri, 2007-12-07 at 13:14 -0500, Shane wrote:
> > On Dec 7, 2007 7:02 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > ...
> > > > 2.6.24-rc3-git1 is last known good kernel. The problem also exists
> > > > with the latest snap 2.6.24-rc4-git4. NFS server is 2.6.23-rc9 and
> > > > is unchanged.
> > >
> > > hm, there have been no nfs changes since 2.6.24-rc4.
> > 
> > Ok, but the problem seems to have appeared before 2.6.24-rc4.
> > 
> > > > It is easily reproducible here, hopefully for the person who
> > > > knows how to debug it too :)
> > > >
> > >
> > > I guess a full set of the commands which you typed to reproduce this would
> > > help.
> > 
> > Server is 2.6.23-rc9 and is exporting:
> > 
> > /dirA/dirB
> > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure,crossmnt)
> > /dirA/dirB/dirC
> > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> > /dirA/dirB/dirD
> > 10.10.20.0/255.255.255.0(rw,async,no_root_squash,no_subtree_check,insecure)
> > 
> > The NFS client (Core2 SMP) 2.6.24-rc3-git4:
> > 
> > NFS-server:/dirA/dirB /dirA/dirBnfs
> > auto,rsize=16384,wsize=16384,hard,intr,users,exec,nfsvers=3,tcp,nolock,actimeo=0
> > 
> > Then on the client when the new kernel has booted:
> > 
> > ls /dirA/dirB  --> normal listing
> > ls /dirA/dirB/dirC   -->  Stale NFS file handle
> > ls /dirA/dirB/dirD   -->  Stale NFS file handle
> > 
> > I will do a few more builds/boots and check -rc3-git2 and -rc3-git3.
> 
> This problem has already been reported. The fix (which I'm planning on
> sending to Linus soon) is appended.
> 

That patch isn't in git://git.linux-nfs.org/pub/linux/nfs-2.6.git.  In fact
that tree is empty.

Has something gone wrong here?
--
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] Fake NUMA emulation for PowerPC

[Balbir Singh]

Nathan Lynch wrote:
> Hi Balbir-
> 
> Balbir Singh wrote:
>>
>> Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
>> NUMA nodes can be specified using the following command line option
>>
>> numa=fake=
>>
>> node range is of the format ,,...
>>
>> Each of the rangeX parameters is passed using memparse(). I find the patch
>> useful for fake NUMA emulation on my simple PowerPC machine. I've tested it
>> on a non-numa box with the following arguments
>>
>> numa=fake=1G
>> numa=fake=1G,2G
>> name=fake=1G,512M,2G
>> numa=fake=1500M,2800M mem=3500M
>> numa=fake=1G mem=512M
>> numa=fake=1G mem=1G
> 
> So this doesn't appear to allow one to assign cpus to fake nodes?  Do
> all cpus just get assigned to node 0 with numa=fake?
> 

Yes, they all appear on node 0. We could have tweaks to distribute CPU's
as well.

> A different approach that occurs to me is to use kexec with a doctored
> device tree (i.e. with the ibm,associativity properties modified to
> reflect your desired topology).  Perhaps a little bit obscure, but it
> seems more flexible.
> 

That would be interesting, but it always means that we need to run
kexec, which might involve two boots.

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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] Fake NUMA emulation for PowerPC

[Nathan Lynch]

Hi Balbir-

Balbir Singh wrote:
> 
> 
> Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
> NUMA nodes can be specified using the following command line option
> 
> numa=fake=
> 
> node range is of the format ,,...
> 
> Each of the rangeX parameters is passed using memparse(). I find the patch
> useful for fake NUMA emulation on my simple PowerPC machine. I've tested it
> on a non-numa box with the following arguments
> 
> numa=fake=1G
> numa=fake=1G,2G
> name=fake=1G,512M,2G
> numa=fake=1500M,2800M mem=3500M
> numa=fake=1G mem=512M
> numa=fake=1G mem=1G

So this doesn't appear to allow one to assign cpus to fake nodes?  Do
all cpus just get assigned to node 0 with numa=fake?

A different approach that occurs to me is to use kexec with a doctored
device tree (i.e. with the ibm,associativity properties modified to
reflect your desired topology).  Perhaps a little bit obscure, but it
seems more flexible.

--
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] Fake NUMA emulation for PowerPC

[Balbir Singh]

Arnd Bergmann wrote:
> On Friday 07 December 2007, Balbir Singh wrote:
>> Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
>> NUMA nodes can be specified using the following command line option
>>
>> numa=fake=
>>
>> node range is of the format ,,...
> 
> Excellent idea! I'd love to have this in RHEL5u1, because that would make
> that distro boot on certain machines that have more memory than is supported
> without an iommu driver. The problem we have is that when you simply
> say mem=1G but all of the first gigabyte is on the first node, you end
> up with a memoryless node, which is not supported.
> 
> Unfortunately, it comes too late for me now, as all new distros already boot
> on Cell machines that need an IOMMU.

Very interesting use case! I am sure there are others were fake NUMA
nodes can be applied. I just listed one other in another email, apart
from using it for playing around with NUMA like machines.

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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.24-rc4-mm1

[Luis R. Rodriguez]

On Dec 6, 2007 9:12 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> Hi,
>
> 2.6.24-rc4-mm1 build failed at drivers/net/wireless/ath5k/base.c for some 
> inline functions like this:
> drivers/net/wireless/ath5k/base.c:292: sorry, unimplemented: inlining failed 
> in call to 'ath5k_extend_tsf': function body not available
>
> fix it with adjust the order of inline function body.
>
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>

Acked-by: Luis R. Rodriguez <[EMAIL PROTECTED]>

Thanks Dave. What version of gcc were you using? I haven't run into this.

BTW, nothing new was added in this patch, things were just shifted,
but even that may be copyrightable. Is it fair to assume you are
licensing these changes under the same license the file is in?

For this file we'd usually use:

Changes-licensed-under: 3-clause-BSD

For future reference:

http://linuxwireless.org/en/developers/Documentation/SubmittingPatches#Changes-licensed-undertag

  Luis
--
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] Fake NUMA emulation for PowerPC

[Balbir Singh]

Kumar Gala wrote:
> 
> On Dec 7, 2007, at 4:12 PM, Balbir Singh wrote:
> 
>> Kumar Gala wrote:
>>>
>>> On Dec 7, 2007, at 3:35 PM, Balbir Singh wrote:
>>>
 Olof Johansson wrote:
> Hi,
>
> On Sat, Dec 08, 2007 at 02:44:25AM +0530, Balbir Singh wrote:
>
>> Comments are as always welcome!
>
> Care to explain what this is useful for? (Not saying it's a stupid
> idea,
> just wondering what the reason for doing it is).
>

 In my case, I use it to test parts of my memory controller patches
 on an
 emulated NUMA machine. I plan to use it to test out page migration
 across nodes.
>>>
>>> Can you explain that further.  I'm still not clear on why this is
>>> useful.
>>>
>>> - k
>>
>> Sure. In my case I need to emulate NUMA nodes to do some NUMA specific
>> testing. The memory controller I've written has some interesting data
>> structures like per node, per zone LRU lists. To be able to test those
>> features on a non-numa box is a problem, since we get just the default
>> node.
> 
> Maybe I'm missing something, what do you mean by memory controller
> you've written?  (I'm use to the term 'memory controller' meaning the
> actual RAM control).
> 

Ah! that explains the disconnect. If you look at the latest -mm tree. We
have a memory controller under control groups, we use it to control how
much memory a group of process can access at a time.

>> To be able to test the memory controller under NUMA, I use fake NUMA
>> nodes. x86-64 has a similar feature, the code I have here is the
>> simplest I could come up with for PowerPC.
>>
>> I just thought of another very interesting use case, it can be used to
>> split up the zone's lru lock which is highly contended.
> 
> - k


-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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] Fake NUMA emulation for PowerPC

[Kumar Gala]

On Dec 7, 2007, at 4:12 PM, Balbir Singh wrote:


Kumar Gala wrote:


On Dec 7, 2007, at 3:35 PM, Balbir Singh wrote:


Olof Johansson wrote:

Hi,

On Sat, Dec 08, 2007 at 02:44:25AM +0530, Balbir Singh wrote:


Comments are as always welcome!


Care to explain what this is useful for? (Not saying it's a  
stupid idea,

just wondering what the reason for doing it is).



In my case, I use it to test parts of my memory controller patches  
on an

emulated NUMA machine. I plan to use it to test out page migration
across nodes.


Can you explain that further.  I'm still not clear on why this is  
useful.


- k


Sure. In my case I need to emulate NUMA nodes to do some NUMA specific
testing. The memory controller I've written has some interesting data
structures like per node, per zone LRU lists. To be able to test those
features on a non-numa box is a problem, since we get just the  
default node.


Maybe I'm missing something, what do you mean by memory controller  
you've written?  (I'm use to the term 'memory controller' meaning the  
actual RAM control).



To be able to test the memory controller under NUMA, I use fake NUMA
nodes. x86-64 has a similar feature, the code I have here is the
simplest I could come up with for PowerPC.

I just thought of another very interesting use case, it can be used to
split up the zone's lru lock which is highly contended.


- k
--
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.22.14 oops msg with commvault galaxy ?

[Randy Dunlap]

On Tue, 04 Dec 2007 13:47:01 + Vincent Fortier wrote:

> Le vendredi 30 novembre 2007 à 12:35 -0500, Fortier,Vincent [Montreal] a
> écrit :
> > > -Message d'origine-
> > > De : Randy Dunlap [mailto:[EMAIL PROTECTED] 
> > > Envoyé : 30 novembre 2007 12:13
> > > 
> > > On Fri, 30 Nov 2007 13:02:54 + Vincent Fortier wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > I'm using a 2.6.22.14 + CFS v24 and I got theses errors 
> > > when starting 
> > > > up my commvault galaxy client...  Do anybody know what this could mean?
> > > 
> > > Can you provide a few lines of syslog before the Oops: line, 
> > > which should contain some info about what happened, e.g.:
> > > 
> > > Unable to handle kernel paging request at virtual address 
> > > e4a85017 printing eip:
> > > c01d915a
> > > *pde = 37d0d067
> > > *pte = 
> > 
> 
> I've umounted the XFS/DRBD filesystem/container (tought it might have
> been related?) but it did not helped... still getting the same kernel
> oops.
> 
> [1097523.808915] BUG: unable to handle kernel paging request at virtual
> address 8000
> [1097523.808950]  printing eip:
> [1097523.808963] c01d915a
> [1097523.808977] *pdpt = 220ea001
> [1097523.808992] *pde = 
> [1097523.809009] Oops:  [#27]
> [1097523.809023] SMP
> [1097523.809040] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd
> nfs_acl sunrpc ppdev parport_pc lp parport button ac battery ipv6 fuse
> ide_cd ide_generic usbkbd usbmouse tsdev serio_raw sg psmouse iTCO_wdt
> iTCO_vendor_support floppy e752x_edac sr_mod pcspkr evdev edac_mc shpchp
> pci_hotplug cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic
> piix ide_core ehci_hcd uhci_hcd tg3 ata_piix usbcore thermal processor
> fan mptscsih mptbase megaraid_sas megaraid_mbox megaraid_mm cciss
> aacraid
> [1097523.809266] CPU:0
> [1097523.809268] EIP:0060:[]Not tainted VLI
> [1097523.809269] EFLAGS: 00010297   (2.6.22.14-cfs-etch-686-envcan #1)
> [1097523.809323] EIP is at vsnprintf+0x2af/0x48c
> [1097523.809341] eax: 8000   ebx:    ecx: 8000   edx:
> fffe
> [1097523.809361] esi: d89c6017   edi: dd1ffeac   ebp:    esp:
> dd1ffe4c
> [1097523.809382] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> [1097523.809403] Process clBackup (pid: 30311, ti=dd1fe000 task=f7043290
> task.ti=dd1fe000)
> [1097523.809423] Stack: dbc2a000 1000 c033b638 f89e056c c02360f1
> dbc2a000 27639fe8 d89c6017
> [1097523.809469]008e2408    
> c0337eab 0003 0017
> [1097523.809512]c037a340 dbc2a000 c01d93b8 dd1ffeac dd1ffeac
> c023566c d89c6017 c0337eaa
> [1097523.809559] Call Trace:
> [1097523.809588]  [] dev_uevent+0x189/0x1e0
> [1097523.809614]  [] sprintf+0x20/0x23
> [1097523.809635]  [] show_uevent+0xad/0xd5
> [1097523.809658]  [] get_page_from_freelist+0x273/0x30a
> [1097523.809686]  [] group_send_sig_info+0x12/0x56
> [1097523.809711]  [] __alloc_pages+0x52/0x286
> [1097523.809734]  [] show_uevent+0x0/0xd5
> [1097523.809754]  [] dev_attr_show+0x15/0x18
> [1097523.809775]  [] sysfs_read_file+0x87/0xd8
> [1097523.809796]  [] sys_getxattr+0x46/0x4e
> [1097523.809818]  [] sysfs_read_file+0x0/0xd8
> [1097523.809839]  [] vfs_read+0xa6/0x128
> [1097523.809861]  [] sys_read+0x41/0x67
> [1097523.809881]  [] syscall_call+0x7/0xb
> [1097523.809906]  ===
> [1097523.809921] Code: 74 24 28 73 03 c6 06 20 4d 46 85 ed 7f f1 e9 b9
> 00 00 00 8b 0f b8 39 0a 33 c0 8b 54 24 30 81 f9 ff 0f 00 00 0f 46 c8 89
> c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 f6 44 24 2c 10 89
> c3
> [1097523.810088] EIP: [] vsnprintf+0x2af/0x48c SS:ESP
> 0068:dd1ffe4c
> 
> Help would really be appreciated.

Let's try the last_sysfs_file (name) patch.
I've attempted to update it for 2.6.22.14.
Andrew, does this change in fs/sysfs/file.c look OK?

---
~Randy



From: Randy Dunlap <[EMAIL PROTECTED]>

Record last_sysfs_file name to print during oopsen so that we can
have a clue.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 arch/i386/kernel/traps.c |6 ++
 fs/sysfs/file.c  |6 ++
 2 files changed, 12 insertions(+)

--- linux-2.6.22.14.orig/arch/i386/kernel/traps.c
+++ linux-2.6.22.14/arch/i386/kernel/traps.c
@@ -411,6 +411,12 @@ void die(const char * str, struct pt_reg
 #endif
if (nl)
printk("\n");
+   {
+   extern char last_sysfs_file[];
+
+   printk(KERN_ALERT "last sysfs file: %s\n",
+   last_sysfs_file);
+   }
if (notify_die(DIE_OOPS, str, regs, err,
current->thread.trap_no, SIGSEGV) !=
NOTIFY_STOP) {
--- linux-2.6.22.14.orig/fs/sysfs/file.c
+++ linux-2.6.22.14/fs/sysfs/file.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -245,6 +246,8 @@ out:
return len;
 

Re: [PATCH] Fake NUMA emulation for PowerPC

[Balbir Singh]

Kumar Gala wrote:
> 
> On Dec 7, 2007, at 3:35 PM, Balbir Singh wrote:
> 
>> Olof Johansson wrote:
>>> Hi,
>>>
>>> On Sat, Dec 08, 2007 at 02:44:25AM +0530, Balbir Singh wrote:
>>>
 Comments are as always welcome!
>>>
>>> Care to explain what this is useful for? (Not saying it's a stupid idea,
>>> just wondering what the reason for doing it is).
>>>
>>
>> In my case, I use it to test parts of my memory controller patches on an
>> emulated NUMA machine. I plan to use it to test out page migration
>> across nodes.
> 
> Can you explain that further.  I'm still not clear on why this is useful.
> 
> - k

Sure. In my case I need to emulate NUMA nodes to do some NUMA specific
testing. The memory controller I've written has some interesting data
structures like per node, per zone LRU lists. To be able to test those
features on a non-numa box is a problem, since we get just the default node.

To be able to test the memory controller under NUMA, I use fake NUMA
nodes. x86-64 has a similar feature, the code I have here is the
simplest I could come up with for PowerPC.

I just thought of another very interesting use case, it can be used to
split up the zone's lru lock which is highly contended.

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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 guidance

[Luke Lu]

On Dec 7, 2007, at 11:36 AM, [EMAIL PROTECTED] wrote:

On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:

Because WORKFLOW C is transparent, it won't affect other  
workflows.  So you
could still use your normal WORKFLOW B in addition to WORKFLOW C,  
gaining an
additional level of version control detail at no extra cost other  
than the

git-engine scratch repository overhead.

BTW, is git efficient enough to handle WORKFLOW C?


Imagine the number of commits a 'make clean; make' will do in a  
kernel tree, as

it commits all those .o files... :)


My guess is that Al is not really a developer (product management/ 
marketing?), what he has in mind is probably not an SCM but a backup  
system a la Mac's time machine or Netapp's snapshots that also  
support disconnected commits. I think that git could be a suitable  
engine for such systems, after a few tweaks to avoid compressing  
already compressed blobs like jpeg, mp3 and mpeg etc.


__Luke
--
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] Fake NUMA emulation for PowerPC

[Balbir Singh]

Arnd Bergmann wrote:
> On Friday 07 December 2007, Balbir Singh wrote:
>> Balbir Singh wrote:
>>> Geert Uytterhoeven wrote:
 On Sat, 8 Dec 2007, Balbir Singh wrote:
> +   if (strstr(p, "fake="))
> +   cmdline = p + 5;/* 5 is faster than strlen("fake=") */
 Really? My gcc is smart enough to replace the `strlen("fake=")' by 5, even
 without -O.

>>> Thanks for pointing that out, but I am surprised that a compiler would
>>> interpret library routines like strlen.
>>>
>> I just tested it and it turns out that you are right. I'll go hunt to
>> see where gcc gets its magic powers from.
>>
> 
> Even if it wasn't: Why the heck would you want to optimize this? The function
> is run _once_ at boot time and the object code gets thrown away afterwards!
> 
>   Arnd <><

Cause, I see no downside of doing it. The strlen of fake= is fixed.
But having said that, I am not a purist about the approach, I just want
cmdline to point after "fake="

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

[Balbir Singh]

> How about running 2.6.24-rc4 with _only_ the patch to this driver to
> convert it to krefs?  Does that combination cause problems?
> 
> The patch is at:
>   
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-convert-hvcs-to-use-kref-not-kobject.patch

This patch works fine with _changes_ on 2.6.24-rc4. I can confirm that
it's not a kref problem in that case. This patch still assumes that
kref_get() returns a value. This is no longer true. The kref_get() call
site needs to be changed.

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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] Fake NUMA emulation for PowerPC

[Arnd Bergmann]

On Friday 07 December 2007, Balbir Singh wrote:
> Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
> NUMA nodes can be specified using the following command line option
> 
> numa=fake=
> 
> node range is of the format ,,...

Excellent idea! I'd love to have this in RHEL5u1, because that would make
that distro boot on certain machines that have more memory than is supported
without an iommu driver. The problem we have is that when you simply
say mem=1G but all of the first gigabyte is on the first node, you end
up with a memoryless node, which is not supported.

Unfortunately, it comes too late for me now, as all new distros already boot
on Cell machines that need an IOMMU.

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