Re: jffs2: -ENOSPC when truncating file?!

[Alexander Belyakov]

On Sun, Feb 24, 2008 at 2:57 AM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
>  I'm trying to free space by truncating big file, and I get:
>
>  [EMAIL PROTECTED]:~# ls -al gps.nmea
>  -rw-r--r--1 root root  2332070 Feb 19 22:13 gps.nmea
>  [EMAIL PROTECTED]:~# > gps.nmea
>  -sh: cannot create gps.nmea: No space left on device
>  [EMAIL PROTECTED]:~# rm gps.nmea
>  [EMAIL PROTECTED]:~# > gps.nmea
>  [EMAIL PROTECTED]:~#
>
>  :-(
>
>  Kernel is not-so-ancient, on openmoko:

Hi!

JFFS2 has known bug in GC leading to -ENOSPC upon file removal. Time
ago I've sent a patch with detailed explanations of what is going on.
Probably your case is the same.

Here is the patch
http://lists.infradead.org/pipermail/linux-mtd/2007-December/020091.html
(though infradead mailing list archive is missing most of messages
from this thread)

And here are some details
http://lists.infradead.org/pipermail/linux-mtd/2007-June/018756.html

Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 kernel: I have 8 Gbytes RAM, but why I can only allocate 2.8 Gbytes RAM for a single process?

[Ady Wicaksono]

I have 8 Gbytes RAM, but why I can allocate 2.8 Gbytes RAM for a single process?
How to patch kernel so I have more than 2.8 Gbytes limitation?

Kernel:
---
Linux xxx.com 2.6.9-023stab046.2-enterprise #1 SMP Mon Dec 10 15:22:33
MSK 2007 i686 i686 i386 GNU/Linux

Mem:
---
# cat /proc/meminfo
MemTotal:  8296484 kB
MemFree: 50416 kB
Buffers: 64412 kB
Cached:4927328 kB
SwapCached:  0 kB
Active:6710828 kB
Inactive:  1065384 kB
HighTotal: 4980736 kB
HighFree: 1024 kB
LowTotal:  3315748 kB
LowFree: 49392 kB
SwapTotal:10256376 kB
SwapFree: 10255732 kB
Dirty:  64 kB
Writeback:   0 kB
Mapped:3054960 kB
Slab:   393224 kB
CommitLimit:  14404616 kB
Committed_AS:  6318152 kB
PageTables:  34892 kB
VmallocTotal:   303096 kB
VmallocUsed: 22360 kB
VmallocChunk:   280496 kB


CPU (8 processor id from 0-7), one of them is:
---
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 6
model name  : Intel(R) Xeon(TM) CPU 3.00GHz
stepping: 4
cpu MHz : 2993.054
cache size  : 2048 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 6
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
lm constant_tsc pni monitor ds_cpl est cid xtpr
bogomips: 5989.55

App to test memory limit:
---
#include 
#include 

int main(){
size_t siz = 100 * 1024 * 1024 ;
size_t idx = 1 ;
void *ptr;

for (;;){
ptr = malloc ( siz * idx );
if(!ptr)
break ;
free(ptr);
idx++;
}
printf ("Max malloc %d * 100 MB \n", idx - 1 );
return (0);
}

App result: Max malloc 28 * 100 MB ==> 2.8 Gbytes


-- 
Regards,

Ady Wicaksono
Email:
ady.wicaksono at gmail.com
http://adywicaksono.wordpress.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 1/3] add a private data field within kobj_attribute structure (final#2)

[Greg KH]

On Mon, Feb 25, 2008 at 03:57:44PM +0900, Kohei KaiGai wrote:
> Greg KH wrote:
>> On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote:
>>> [PATCH 1/3] add a private data field within kobj_attribute structure.
>>>
>>> This patch add a private data field, declared as void *, within 
>>> kobj_attribute
>>> structure. The _show() and _store() method in the sysfs attribute entries 
>>> can
>>> refer this information to identify what entry is accessed.
>>> It makes easier to share a single method implementation with several 
>>> similar
>>> entries, like ones to export the list of capabilities the running kernel
>>> supports.
>>>
>>> Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
>>> --
>>>  Documentation/kobject.txt |6 ++
>> That's good, but you didn't modify the sample/kobject/ file to use the
>> new void pointer, instead of the strcmp() call.
>
> The 3/3 of patches updates sample/kobject to use the new void pointer.
> Do you want it to replace strcmp() examples completly?

Doh, I totally missed that one, very sorry.  I'll be glad to take
patches 1 and 3 in my tree, if you want me to.

thanks,

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

Re: [PATCH] x86: EFI_PAGE_SHIFT fix

[Ingo Molnar]

* Huang, Ying <[EMAIL PROTECTED]> wrote:

> Make x86 EFI code works when EFI_PAGE_SHIFT != PAGE_SHIFT. The 
> memrage_efi_to_native() provided in this patch can be used on other 
> EFI platform such as IA64 too.
> 
> This patch has been tested on Intel x86_64 platform with EFI 64/32 
> firmware.

this is mostly cosmetic, isnt it - because currently nobody expects 
EFI_PAGE_SHIFT and PAGE_SHIFT to ever change on x86, right? I've queued 
up your patch for 2.6.26, ok?

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

Re: [PATCH] maple: fix device detection

[Adrian McMenamin]

On Mon, 2008-02-25 at 14:33 +0900, Paul Mundt wrote:
> On Sun, Feb 24, 2008 at 10:32:53PM +, Adrian McMenamin wrote:
> > On Sun, 2008-02-24 at 21:50 +, Adrian McMenamin wrote:
> > > On Sun, 2008-02-24 at 14:30 +, Adrian McMenamin wrote:
> > > > The maple bus driver that went into the kernel mainline in
> > > > September 2007 contained some bugs which were revealed by the
> > > > update of the kobj code for the current release series.
> > > > Unfortunately those bugs also helped ensure maple devices were
> > > > properly detected. This patch (against the current git) now ensures
> > > > that devices are properly detected again.
> > > > 
> > > 
> > > Further testing has shown this has introduced another bug, this time
> > > limiting the effectiveness of subdevice detection. Please ignore this
> > > while I work on a fix.
> > > 
> > Sorry for the confusion, in fact there is nothing wrong with this code
> > (ie it should be applied), the error was in the driver for the Dreamcast
> > controller (the device, in general, into which the subdevices are
> > plugged in and out).
> > 
> > I will post a fix for that.
> > 
> > Sorry again.
> > 
> So what exactly is supposed to be applied here?

The patch at the start of this thread - ie
http://lkml.org/lkml/2008/2/24/125  - this should really go in now as it
fixes a problem with current code.

In addition there are two patch sets to add new device support:

http://lkml.org/lkml/2008/2/24/211- maple controller

http://lkml.org/lkml/2008/2/24/121  (thread) - maple mouse

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Clocksource tsc is always unstable with 2.6.25-* kernels and CONFIG_NO_HZ=y on my box

[Thomas Gleixner]

On Sun, 24 Feb 2008, Robert Hancock wrote:
> Gabriel C wrote:
> > Hi,
> > 
> > I noticed tsc is always marked unstable on my box with 2.6.25* , 2.6.24 is
> > fine.
> > 
> > ..
> > 
> > [0.825760] ACPI: PCI Interrupt :03:0e.0[A] -> GSI 22 (level, low) ->
> > IRQ 22
> > [0.805755] Switched to high resolution mode on CPU 1
> > [0.794244] Switched to high resolution mode on CPU 2
> > [0.766968] Switched to high resolution mode on CPU 3
> > [1.083944] Switched to high resolution mode on CPU 0
> > [   15.388792] Clocksource tsc unstable (delta = 9373391604 ns)

Doh, this looks like the acpi_pm timer is not working at all.

> > [   15.714648] Time: acpi_pm clocksource has been installed.
> > ..
> > 
> > Booting nohz=off fixes that.
> > 
> > Another strange thing is when I try to boot that kernel with
> > clocksource=acpi_pm it just hangs.

Which confirms the above.
 
> > config is attached.
> > 
> > Please let me know if you need more infos / want me to try patches or
> > anything else.
> 
> Please post your full dmesg output.

Yes please.

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: [PATCH 1/2] Kprobes: Indicate kretprobe support in Kconfig

[Ingo Molnar]

* Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote:

> From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
> 
> This patch adds CONFIG_HAVE_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.

Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

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

Re: [Bluez-devel] forcing SCO connection patch

[Dave Young]

On Mon, Feb 25, 2008 at 3:30 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> Quote mail from [EMAIL PROTECTED] :
>
>  2007/12/17 Louis JANG <[EMAIL PROTECTED]>:
>
>
> > Hello everybody,
>  >
>  >  I attached two patches. the first one(bluez-kernel-forcesco.patch) is to
>  >  force using HCI_OP_ADD_SCO instead of HCI_OP_SETUP_SYNC_CONN, and the
>  >  second one is to handle SCO connection complete event but its request
>  >  was ESCO.
>  >
>  >  1.
>  >  I'm developing bluetooth functions in my linux phone project, and I'm
>  >  using bluez for my job. I've tested lots of headsets, and found that I
>  >  coudn't connect SCO channel with HCI_OP_SETUP_SYNC_CONN in some old
>  >  headsets. I could connect SCO channel with HCI_OP_ADD_SCO in this case.
>  >  however, there is no api to force using SCO instead of ESCO in bluez. so
>  >  I added SCO_FORCESCO to handle this old headsets
>  >
>  >  2.
>  >  When I tried to connect SCO channel with
>  >  HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets responds
>  >  with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't
>  >  handle this situation, and patch_hci_event.c is for this.
>  >
>  >
>  >  BRs
>  >  Louis JANG
>  >
>  >
>
>  Reply from [EMAIL PROTECTED]:
>
>  On Mon, Feb 25, 2008 at 2:43 PM, Brad Midgley <[EMAIL PROTECTED]> wrote:
>  > Louis
>
> >
>  >
>  >  >  When I tried to connect SCO channel with
>  >  >  HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets 
> responds
>  >  >  with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't
>  >  >  handle this situation, and patch_hci_event.c is for this.
>  >
>
> >  Marcel looked at this patch and came back with the comments below. Can
>  >  you revisit it? I think some other people are seeing the same issues.
>  >  The patch won't go upstream until Marcel likes it.
>  >
>  >  the patch you sent me is fully broken. First of all the coding style
>  >  is wrong. Does nobody have learned this by now? I always look for that
>  >  first before even reading the patch. Second the case where an
>  >  ESCO_LINK returns NULL is broken and will fall over and crash.
>  >
>  >  --
>  >  Brad
>  >
>
>
>  I ever asked marcel about the coding style. please see following thread:
>  http://lkml.org/lkml/2008/1/22/91
>
>  I think the style problem marcel said is
>  1. using kernel codeing style
>  2. marcel's style
>  container_of or get_user_data calls at the top of the variable declaration
>  using the empty lines to seperate code blocks
>
>  Please rework your patch and resend if you fixed them.
>
>  BTW, please use the new bluetooth mailing list for kerne issue.
>  [EMAIL PROTECTED]
>
>  (Thanks for andrew and davem)

On bugzilla, bug 9871 are same problem as yours.

add davem and netdev in cc-list

>
>  Regards
>  dave
>
>  Regards
>  dave
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 3/3] IDE: Coding Style fixes to drivers/ide/pci/cy82c693.c

[Ingo Molnar]

* Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote:

> Before:
> total: 34 errors, 14 warnings, 456 lines checked
> 
> After:
> total: 0 errors, 8 warnings, 456 lines checked

sidenote: please also indicate to maintainers that the cleanup causes no 
change in generated code. Find below of how one of your cleanup patches 
looks like in its final form in x86.git. (i auto-generated all of the 
commit log)

info like that makes it easier for maintainers to see the intended zero 
impact of your changes.

Ingo

-->
Subject: x86: coding style fixes to arch/x86/kernel/vm86_32.c
From: Paolo Ciarrocchi <[EMAIL PROTECTED]>
Date: Fri, 22 Feb 2008 23:10:40 +0100

Before:
   total: 64 errors, 18 warnings, 840 lines checked
After:
   total: 12 errors, 15 warnings, 844 lines checked

No code changed:

arch/x86/kernel/vm86_32.o:

   textdata bss dec hex filename
   4449  28 13246091201 vm86_32.o.before
   4449  28 13246091201 vm86_32.o.after

md5:
   e4e51ed7689d17f04148554a3c6d5bb6  vm86_32.o.before.asm
   e4e51ed7689d17f04148554a3c6d5bb6  vm86_32.o.after.asm

Signed-off-by: Paolo Ciarrocchi <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 arch/x86/kernel/vm86_32.c |  174 +++---
 1 file changed, 89 insertions(+), 85 deletions(-)

Index: linux-x86.q/arch/x86/kernel/vm86_32.c
===
--- linux-x86.q.orig/arch/x86/kernel/vm86_32.c
+++ linux-x86.q/arch/x86/kernel/vm86_32.c
@@ -64,7 +64,7 @@
 
 
 #define KVM86  ((struct kernel_vm86_struct *)regs)
-#define VMPI   KVM86->vm86plus
+#define VMPI   KVM86->vm86plus
 
 
 /*
@@ -81,7 +81,7 @@
 #define VFLAGS (*(unsigned short *)&(current->thread.v86flags))
 #define VEFLAGS(current->thread.v86flags)
 
-#define set_flags(X,new,mask) \
+#define set_flags(X, new, mask) \
 ((X) = ((X) & ~(mask)) | ((new) & (mask)))
 
 #define SAFE_MASK  (0xDD5)
@@ -93,8 +93,10 @@ static int copy_vm86_regs_to_user(struct
 {
int ret = 0;
 
-   /* kernel_vm86_regs is missing gs, so copy everything up to
-  (but not including) orig_eax, and then rest including orig_eax. */
+   /*
+* kernel_vm86_regs is missing gs, so copy everything up to
+* (but not including) orig_eax, and then rest including orig_eax.
+*/
ret += copy_to_user(user, regs, offsetof(struct kernel_vm86_regs, 
pt.orig_ax));
ret += copy_to_user(>orig_eax, >pt.orig_ax,
sizeof(struct kernel_vm86_regs) -
@@ -120,7 +122,7 @@ static int copy_vm86_regs_from_user(stru
return ret;
 }
 
-struct pt_regs * save_v86_state(struct kernel_vm86_regs * regs)
+struct pt_regs *save_v86_state(struct kernel_vm86_regs *regs)
 {
struct tss_struct *tss;
struct pt_regs *ret;
@@ -138,8 +140,8 @@ struct pt_regs * save_v86_state(struct k
do_exit(SIGSEGV);
}
set_flags(regs->pt.flags, VEFLAGS, VIF_MASK | current->thread.v86mask);
-   tmp = copy_vm86_regs_to_user(>thread.vm86_info->regs,regs);
-   tmp += 
put_user(current->thread.screen_bitmap,>thread.vm86_info->screen_bitmap);
+   tmp = copy_vm86_regs_to_user(>thread.vm86_info->regs, regs);
+   tmp += put_user(current->thread.screen_bitmap, 
>thread.vm86_info->screen_bitmap);
if (tmp) {
printk("vm86: could not access userspace vm86_info\n");
do_exit(SIGSEGV);
@@ -237,20 +239,21 @@ asmlinkage int sys_vm86(struct pt_regs r
 
tsk = current;
switch (regs.bx) {
-   case VM86_REQUEST_IRQ:
-   case VM86_FREE_IRQ:
-   case VM86_GET_IRQ_BITS:
-   case VM86_GET_AND_RESET_IRQ:
-   ret = do_vm86_irq_handling(regs.bx, (int)regs.cx);
-   goto out;
-   case VM86_PLUS_INSTALL_CHECK:
-   /* NOTE: on old vm86 stuff this will return the error
-  from access_ok(), because the subfunction is
-  interpreted as (invalid) address to vm86_struct.
-  So the installation check works.
-*/
-   ret = 0;
-   goto out;
+   case VM86_REQUEST_IRQ:
+   case VM86_FREE_IRQ:
+   case VM86_GET_IRQ_BITS:
+   case VM86_GET_AND_RESET_IRQ:
+   ret = do_vm86_irq_handling(regs.bx, (int)regs.cx);
+   goto out;
+   case VM86_PLUS_INSTALL_CHECK:
+   /*
+* NOTE: on old vm86 stuff this will return the error
+*  from access_ok(), because the subfunction is
+*  interpreted as (invalid) address to vm86_struct.
+*  So the installation check works.
+*/
+   ret = 0;
+   goto out;
}
 
/* we come here only for functions VM86_ENTER, 

Re: [PATCH 03/10] PCI: AMD SATA IDE mode quirk

[Grant Grundler]

On Mon, Feb 25, 2008 at 09:43:59AM +0800, Cai, Crane wrote:
> > On Fri, Feb 22, 2008 at 01:49:20PM +0800, Cai, Crane wrote:
> > > > On Thu, Feb 21, 2008 at 03:47:33PM -0800, Greg 
> > Kroah-Hartman wrote:
> > > > > +static void __devinit quirk_amd_ide_mode(struct pci_dev *pdev)
> > > > >  {
> > > > > - /* set sb600 sata to ahci mode */
> > > > > - if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> > > > > - u8 tmp;
> > > > > + /* set sb600/sb700/sb800 sata to ahci mode */
> > > > > + u8 tmp;
> > > > >  
> > > > > + pci_read_config_byte(pdev, PCI_CLASS_DEVICE, );
> > > > > + if (tmp == 0x01) {
> > > > >   pci_read_config_byte(pdev, 0x40, );
> > > > 
> > > > This seems like a dis-improvement.  Why are we reading a 
> > config byte 
> > > > for something we already have in the pci_dev?
> > > > Why are we now checking against 0x01 instead of a 
> > symbolic constant?  
> > > > Why are we no longer checking that this is PCI_BASE_CLASS_STORAGE?
> > > It is a quirk. In pci_ids.h did have PCI_CLASS_STORAGE_IDE and 
> > > PCI_BASE_CLASS_STORAGE, these can not represent the right 
> > situation we 
> > > want to check. 0x01 represents PCI_CLASS_STORAGE_IDE last 2 
> > bit. Also 
> > > because it is a quirk, I do not think we need to change 
> > pci_ids.h. So 
> > > 0x01 used.
> > 
> > You haven't explained what is wrong with the original code:
> > 
> > if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> > 
> 
> When resume, this pdev->class is quirked, however BIOS has
> modified pci configuration too. Inconsistance occurs.

Can you update pdev->class from the quirk?
It would be consistent then.
That would leave the code as-is except it's re-reading the field
from config space.

hth,
grant

> > > > Nothing in the changelog entry suggests why we now need 
> > FIXUP_RESUME 
> > > > entries when we didn't before.
> > > > 
> > > PCI configuration space will be changed by BIOS and then in 
> > pci init 
> > > and restore. So resume also needed.
> > 
> > That information needed to be in the changelog.
> 
> This info, is a normal info. If maintainer need us to added in source code. I 
> preferred too. 
> > --
> > Intel are signing my paycheques ... these opinions are still 
> > mine "Bill, look, we understand that you're interested in 
> > selling us this operating system, but compare it to ours.  We 
> > can't possibly take such a retrograde step."
> > 
> > 
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Jeff Garzik]

Grant Grundler wrote:

On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote:
I think that de2104x driver should be removed (or at least its 
MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI 
IDs added to de4x5.


I can send a patch if this is acceptable.


It's acceptable to me. Jeff? (jgarzik)


NAK, sorry, for two reasons:

1) we don't delete otherwise clean, working drivers simply because of a 
bug triggered by unplugging a cable.


2) de4x5 needs to go away.

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: [Bluez-devel] forcing SCO connection patch

[Dave Young]

Quote mail from [EMAIL PROTECTED] :

2007/12/17 Louis JANG <[EMAIL PROTECTED]>:
> Hello everybody,
>
>  I attached two patches. the first one(bluez-kernel-forcesco.patch) is to
>  force using HCI_OP_ADD_SCO instead of HCI_OP_SETUP_SYNC_CONN, and the
>  second one is to handle SCO connection complete event but its request
>  was ESCO.
>
>  1.
>  I'm developing bluetooth functions in my linux phone project, and I'm
>  using bluez for my job. I've tested lots of headsets, and found that I
>  coudn't connect SCO channel with HCI_OP_SETUP_SYNC_CONN in some old
>  headsets. I could connect SCO channel with HCI_OP_ADD_SCO in this case.
>  however, there is no api to force using SCO instead of ESCO in bluez. so
>  I added SCO_FORCESCO to handle this old headsets
>
>  2.
>  When I tried to connect SCO channel with
>  HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets responds
>  with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't
>  handle this situation, and patch_hci_event.c is for this.
>
>
>  BRs
>  Louis JANG
>
>

Reply from [EMAIL PROTECTED]:

On Mon, Feb 25, 2008 at 2:43 PM, Brad Midgley <[EMAIL PROTECTED]> wrote:
> Louis
>
>
>  >  When I tried to connect SCO channel with
>  >  HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets responds
>  >  with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't
>  >  handle this situation, and patch_hci_event.c is for this.
>
>  Marcel looked at this patch and came back with the comments below. Can
>  you revisit it? I think some other people are seeing the same issues.
>  The patch won't go upstream until Marcel likes it.
>
>  the patch you sent me is fully broken. First of all the coding style
>  is wrong. Does nobody have learned this by now? I always look for that
>  first before even reading the patch. Second the case where an
>  ESCO_LINK returns NULL is broken and will fall over and crash.
>
>  --
>  Brad
>


I ever asked marcel about the coding style. please see following thread:
http://lkml.org/lkml/2008/1/22/91

I think the style problem marcel said is
1. using kernel codeing style
2. marcel's style
container_of or get_user_data calls at the top of the variable declaration
using the empty lines to seperate code blocks

Please rework your patch and resend if you fixed them.

BTW, please use the new bluetooth mailing list for kerne issue.
[EMAIL PROTECTED]

(Thanks for andrew and davem)

Regards
dave

Regards
dave
-
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Jeff Garzik]

Grant Grundler wrote:

ISTR there was a time when tulip would compete with de4x5 for devices.
tulip is the preferred driver. That's clearly no longer the case
and perhaps both distro's need to revisit this.


The only reason why de4x5 still exists is that the /tulip/ driver fails 
to work on a few chips like the 21142 (43?) shipped in various alpha boxen.


de4x5 needs to go away, it's been unmaintained for ages, doesn't support 
any of the new hotplug APIs.




de2104x is a "work in progress".
That's why it's marked "EXPERIMENTAL" in the Kconfig file.


It's not a work in progress, it works just fine for most people (the few 
that are left).


Last I heard, there was a problem with non-twisted-pair stuff, but 
that's about it.


'experimental' is generally a poorly maintained marker.

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: 2.6.26-git0: IDE oops during boot

[Yinghai Lu]

On Sun, Feb 24, 2008 at 11:05 PM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 15, 2008 at 3:15 AM, Kamalesh Babulal
>
> <[EMAIL PROTECTED]> wrote:
>  >
>  >
>
> >  Thanks for pointing the patch, I do not have the SES config option enabled,
>  >  then too i tried your patch, but that does not solve the panic. The kernel
>  >  panic's with the same panic message as before. I have attached the .config
>  >  file which i am using, please let me know if i am missing out/getting 
> wrong
>  >  any option in the configuration.
>
>  can you try x86.git#testing?
>
>  http://people.redhat.com/mingo/x86.git/README
>

and try attached patch.

YH
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 6fd804f..f0d6a80 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -801,7 +801,7 @@ static void __cpuinit srat_detect_node(void)
 	/* Don't do the funky fallback heuristics the AMD version employs
 	   for now. */
 	node = apicid_to_node[apicid];
-	if (node == NUMA_NO_NODE)
+	if (node == NUMA_NO_NODE || !node_online(node))
 		node = first_node(node_online_map);
 	numa_set_node(cpu, node);
 

Re: Linux 2.6.25-rc3

[Ingo Molnar]

* S.Çağlar Onur <[EMAIL PROTECTED]> wrote:

> 25 Şub 2008 Pts tarihinde, Linus Torvalds şunları yazmıştı: 
> > 
> > Ok, it's out there, ready for your enjoyment.
> [...] 
> > So give it a good testing, please,
> 
> -rc3 still fails for this [1] config

this is lguest breakage. I've got the fixes for it in x86.git, will push 
them to Linus later today if Rusty doesnt object.

> -#ifdef CONFIG_LGUEST
> +#if defined(CONFIG_LGUEST) || defined(CONFIG_LGUEST_MODULE)

this fix still fails for some randconfig combinations - the fuller fix 
is queued up in x86.git#testing.

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

[PATCH] x86: EFI_PAGE_SHIFT fix

[Huang, Ying]

Make x86 EFI code works when EFI_PAGE_SHIFT != PAGE_SHIFT. The
memrage_efi_to_native() provided in this patch can be used on other
EFI platform such as IA64 too.

This patch has been tested on Intel x86_64 platform with EFI 64/32
firmware.

Signed-off-by: Huang Ying <[EMAIL PROTECTED]>

---
 arch/x86/kernel/efi.c|   18 +-
 arch/x86/kernel/efi_64.c |   12 ++--
 include/linux/efi.h  |7 +++
 3 files changed, 26 insertions(+), 11 deletions(-)

--- a/arch/x86/kernel/efi.c
+++ b/arch/x86/kernel/efi.c
@@ -383,6 +383,7 @@ static void __init runtime_code_page_mke
 {
efi_memory_desc_t *md;
void *p;
+   u64 addr, npages;
 
/* Make EFI runtime service code area executable */
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
@@ -391,7 +392,10 @@ static void __init runtime_code_page_mke
if (md->type != EFI_RUNTIME_SERVICES_CODE)
continue;
 
-   set_memory_x(md->virt_addr, md->num_pages);
+   addr = md->virt_addr;
+   npages = md->num_pages;
+   memrange_efi_to_native(, );
+   set_memory_x(addr, npages);
}
 }
 
@@ -408,7 +412,7 @@ void __init efi_enter_virtual_mode(void)
efi_memory_desc_t *md;
efi_status_t status;
unsigned long size;
-   u64 end, systab;
+   u64 end, systab, addr, npages;
void *p, *va;
 
efi.systab = NULL;
@@ -420,7 +424,7 @@ void __init efi_enter_virtual_mode(void)
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;
 
-   if ((end >> PAGE_SHIFT) <= max_pfn_mapped)
+   if (PFN_UP(end) <= max_pfn_mapped)
va = __va(md->phys_addr);
else
va = efi_ioremap(md->phys_addr, size);
@@ -433,8 +437,12 @@ void __init efi_enter_virtual_mode(void)
continue;
}
 
-   if (!(md->attribute & EFI_MEMORY_WB))
-   set_memory_uc(md->virt_addr, md->num_pages);
+   if (!(md->attribute & EFI_MEMORY_WB)) {
+   addr = md->virt_addr;
+   npages = md->num_pages;
+   memrange_efi_to_native(, );
+   set_memory_uc(addr, npages);
+   }
 
systab = (u64) (unsigned long) efi_phys.systab;
if (md->phys_addr <= systab && systab < end) {
--- a/arch/x86/kernel/efi_64.c
+++ b/arch/x86/kernel/efi_64.c
@@ -105,14 +105,14 @@ void __init efi_reserve_bootmem(void)
 
 void __iomem * __init efi_ioremap(unsigned long phys_addr, unsigned long size)
 {
-   static unsigned pages_mapped;
+   static unsigned pages_mapped __initdata;
unsigned i, pages;
+   unsigned long offset;
 
-   /* phys_addr and size must be page aligned */
-   if ((phys_addr & ~PAGE_MASK) || (size & ~PAGE_MASK))
-   return NULL;
+   pages = PFN_UP(phys_addr + size) - PFN_DOWN(phys_addr);
+   offset = phys_addr & ~PAGE_MASK;
+   phys_addr &= PAGE_MASK;
 
-   pages = size >> PAGE_SHIFT;
if (pages_mapped + pages > MAX_EFI_IO_PAGES)
return NULL;
 
@@ -124,5 +124,5 @@ void __iomem * __init efi_ioremap(unsign
}
 
return (void __iomem *)__fix_to_virt(FIX_EFI_IO_MAP_FIRST_PAGE - \
-(pages_mapped - pages));
+(pages_mapped - pages)) + offset;
 }
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -394,4 +395,10 @@ struct efi_generic_dev_path {
u16 length;
 } __attribute ((packed));
 
+static inline void memrange_efi_to_native(u64 *addr, u64 *npages)
+{
+   *npages = PFN_UP(*addr + (*npages

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

[Grant Grundler]

On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote:
> On Monday 18 February 2008 04:21:11 Grant Grundler wrote:
> > On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
> > > On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
> > > > Hello,
> > > > I was having problems with these FreedomLine cards with Linux before
> > > > but tested it thoroughly today. This card uses DEC 21041 chip and has
> > > > TP and BNC connectors:
> > > >
> > > > 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation
> > > > DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)
> > > >
> > > >
> > > > de2104x driver was loaded automatically by udev and card seemed to
> > > > work. Until I disconnected the TP cable and putting it back after a
> > > > while. The driver then switched to (non-existing) AUI port and remained
> > > > there. I tried to set media to TP using ethtool - and the whole kernel
> > > > crashed because of BUG_ON(de_is_running(de));
> > > > in de_set_media(). Seems that the driver is unable to stop the DMA in
> > > > de_stop_rxtx().
> >
> > The BUG_ON() is probably fine normally. But the media selection sounds
> > broken. It's possible to select the wrong media type with 21040 chip but
> > shouldn't be possible with 21041. For 21040 support, see
> > de21040_get_media_info(). But de21041_get_srom_info() is expected to
> > determine which media
> > types are supported from SEPROM "media blocks".   My guess is that code
> > is broken since it seems to work with de405 driver. If you care to
> > work the difference, I'd be happy to make a patch to fix that up.
> 
> I don't think that BUG_ON() should be there. It should probably printk a 
> warning but certainly not crash the whole machine.

Ah ok - I agree. I'll see if we can fail more gracfully there.
If you have an idea already, please send me a patch.

> > > > Then I found that there's de4x5 driver which supports the same cards as
> > > > de2104x (and some other too) - and this one works fine! I can plug and
> > > > unplug the cable and even change between TP and BNC ports just by
> > > > unplugging one and plugging the other cable in. Unfortunately, this
> > > > driver is blacklisted by default - at least in Slackware and Debian.
> >
> > ISTR there was a time when tulip would compete with de4x5 for devices.
> > tulip is the preferred driver. That's clearly no longer the case
> > and perhaps both distro's need to revisit this.
> 
> de4x5 has no MODULE_DEVICE_TABLE for PCI devices anymore, so no conflicts. 
> That's probably good for cards that work with tulip driver but bad for mine 
> card and also probably for some other cards that (should) work with de2104x.
> 
> >
> > > > The question is: why does de2104x exist? Does it work better with some
> > > > hardware?
> >
> > de2104x is a "work in progress".
> > That's why it's marked "EXPERIMENTAL" in the Kconfig file.
> 
> Great, it looks to be 6 years old and it's still experimental. Probably 
> because it never worked properly.

Yeah, probably.

> I think that de2104x driver should be removed (or at least its 
> MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI 
> IDs added to de4x5.
> 
> I can send a patch if this is acceptable.

It's acceptable to me. Jeff? (jgarzik)

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

Re: 2.6.26-git0: IDE oops during boot

[Yinghai Lu]

On Fri, Feb 15, 2008 at 3:15 AM, Kamalesh Babulal
<[EMAIL PROTECTED]> wrote:
>
>
>  Thanks for pointing the patch, I do not have the SES config option enabled,
>  then too i tried your patch, but that does not solve the panic. The kernel
>  panic's with the same panic message as before. I have attached the .config
>  file which i am using, please let me know if i am missing out/getting wrong
>  any option in the configuration.

can you try x86.git#testing?

http://people.redhat.com/mingo/x86.git/README

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] add a private data field within kobj_attribute structure (final#2)

[Kohei KaiGai]

Greg KH wrote:

On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote:

[PATCH 1/3] add a private data field within kobj_attribute structure.

This patch add a private data field, declared as void *, within kobj_attribute
structure. The _show() and _store() method in the sysfs attribute entries can
refer this information to identify what entry is accessed.
It makes easier to share a single method implementation with several similar
entries, like ones to export the list of capabilities the running kernel
supports.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 Documentation/kobject.txt |6 ++


That's good, but you didn't modify the sample/kobject/ file to use the
new void pointer, instead of the strcmp() call.


The 3/3 of patches updates sample/kobject to use the new void pointer.
Do you want it to replace strcmp() examples completly?

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

Re: [RFC] [PATCH] To refuse users from probing preempt_schedule()

[Srinivasa DS]

On Monday 25 February 2008 11:50:24 am Dave Hansen wrote:
> On Mon, 2008-02-25 at 11:27 +0530, srinivasa wrote:
> > This patch prohibits user from probing preempt_schedule(). One way of
> > prohibiting the user from probing functions is by marking such
> > functions with __kprobes. But this method doesn't work for those
> > functions, which are already marked to different section like
> > preempt_schedule() (belongs to __sched section). So we use blacklist
> > approach to refuse user from probing these functions.
>
> preempt_schedule() does sound really, really important.  But, what kinds
> of functions can't be kprobed?  
  
Normally we don't allow user to probe those functions, which are used by 
kprobes internally while registering probe on user specified address.  For 
example kprobes internally makes use of preempt_disable()(this in turn calls 
add_preempt_count()), so we prohibit users from probing add_preempt_count() 
function.  To get comprehensive list of functions which are prohibited from 
probing, please have a look at functions which are marked under __kprobes. 
 
> It would be nice to give that blacklist 
> a nice comment on the topic. :)

Yes, I  have added comments on the blacklist approach in 
 1)init_kprobes(), where we populate entries  for kprobe blacklist.
 2) in_kprobe_function(), where we verify the user specified address with 
the start and end of the blacklisted function.

>
> Also, have you strained your brains to think of other functions that
> this should be applied to?  Is it just for functions that are sensitive
> and already have an assigned section? 

Yes, this kprobes blacklist approach is only for those functions which are 
sensitive and are already assigned to different sections. Right now, 
there is no other function, except preempt_schedule() which satisfies above 
condition. But in future if we encounter any such functions we surely add 
them kprobe blacklist.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bcm43xx regression in 2.6.24 (with patch)

[Pekka J Enberg]

Hi Greg,

On Sun, 24 Feb 2008, Greg KH wrote:
> > Lets make this simple: it used to work before and now it doesn't. 
> > Therefore it's a regression that must be addressed. Period.
> 
> Isn't the resolution Michael is suggesting is, "use the different driver"?

Alexey said it didn't work but even if it did, we don't let old drivers 
_regress_ as long as they're in the tree. There are plenty of precedents 
here so I don't see why this particular Broadcom driver is any different.

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Change a WARN message in checkpatch

[Paolo Ciarrocchi]

On 2/25/08, Andy Whitcroft
> As we want the messages to be as short as possible, I am leaning towards
> standardising on:
>
> spaces prohibited 
> spaces required 
>
in that case i would prefer:
 space not required 
 space required 

ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.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 1/3] add a private data field within kobj_attribute structure (final#2)

[Greg KH]

On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote:
> [PATCH 1/3] add a private data field within kobj_attribute structure.
> 
> This patch add a private data field, declared as void *, within kobj_attribute
> structure. The _show() and _store() method in the sysfs attribute entries can
> refer this information to identify what entry is accessed.
> It makes easier to share a single method implementation with several similar
> entries, like ones to export the list of capabilities the running kernel
> supports.
> 
> Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
> --
>  Documentation/kobject.txt |6 ++

That's good, but you didn't modify the sample/kobject/ file to use the
new void pointer, instead of the strcmp() call.

thanks,

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

Re: bcm43xx regression in 2.6.24 (with patch)

[Greg KH]

On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote:
> Hi Michael,
> 
> On Sun, 24 Feb 2008, Michael Buesch wrote:
> > > The ony way I see this was possible, you manually changed the
> > > module loading order, so that the b43xx module was loaded prior
> > > to the ssb and b44 modules. Right?
> > 
> > Right. So "so I'm left with either no wifi or no ethenet" being wrong.
> 
> Lets make this simple: it used to work before and now it doesn't. 
> Therefore it's a regression that must be addressed. Period.

Isn't the resolution Michael is suggesting is, "use the different driver"?

thanks,

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

Re: [PATCH 2/3] IDE: Replace __FUNCTION__ with __func__

[Paolo Ciarrocchi]

On 2/25/08, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-02-24 at 22:11 +0100, Paolo Ciarrocchi wrote:
> > -   "driver.\n", __FUNCTION__, drive->name);
> > +   "driver.\n", __func__, drive->name);
>
> Is there consensus on this style conversion?

I did that in a separate patch because i'm not sure about that.

> Right now, there's 629 uses of __FUNCTION__ and 439 uses of __func__.

Checkpatch.pl indicate the conversion as a janitorial task.

Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.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/

[PATCH] Resume TTY on SUSP and fix CRNL order in N_TTY line discipline

[Joe Peterson]

Here is a small patch to further refine behavior in n_tty.c.  It
addresses two fine points in how received characters are treated - one
to handle the signal chars in stopped TTYs more consistently, and the
other to make the order of cr/nl translations more logical and
consistent with other Unixes when unusual stty settings are used (e.g.
if someone were to set intr to ^J).

-Joe
Refine these behaviors in the N_TTY line discipline:

1) Handle the signal characters consistently when received in
   a stopped TTY so that SUSP (typically ctrl-Z) behaves like
   INTR and QUIT in resuming a stopped TTY.

2) Adjust the order in which the IGNCR/ICRNL/INLCR processing
   is applied to be more logical and consistent with the behavior
   of other Unix systems.

Signed-off-by: Joe Peterson <[EMAIL PROTECTED]>
---

diff -puN 
drivers/char/n_tty.c~resume-tty-on-susp-and-fix-crnl-order-in-n_tty-line-discipline
 drivers/char/n_tty.c
--- 
a/drivers/char/n_tty.c~resume-tty-on-susp-and-fix-crnl-order-in-n_tty-line-discipline
   2008-02-24 08:36:24.0 -0700
+++ a/drivers/char/n_tty.c  2008-02-24 21:08:15.0 -0700
@@ -701,7 +701,7 @@ static inline void n_tty_receive_char(st
 
if (tty->stopped && !tty->flow_stopped && I_IXON(tty) &&
((I_IXANY(tty) && c != START_CHAR(tty) && c != STOP_CHAR(tty)) ||
-c == INTR_CHAR(tty) || c == QUIT_CHAR(tty)))
+c == INTR_CHAR(tty) || c == QUIT_CHAR(tty) || c == SUSP_CHAR(tty)))
start_tty(tty);
 
if (tty->closing) {
@@ -739,13 +739,6 @@ static inline void n_tty_receive_char(st
return;
}
 
-   if (c == '\r') {
-   if (I_IGNCR(tty))
-   return;
-   if (I_ICRNL(tty))
-   c = '\n';
-   } else if (c == '\n' && I_INLCR(tty))
-   c = '\r';
if (I_IXON(tty)) {
if (c == START_CHAR(tty)) {
start_tty(tty);
@@ -756,6 +749,7 @@ static inline void n_tty_receive_char(st
return;
}
}
+
if (L_ISIG(tty)) {
int signal;
signal = SIGINT;
@@ -785,6 +779,15 @@ send_signal:
return;
}
}
+
+   if (c == '\r') {
+   if (I_IGNCR(tty))
+   return;
+   if (I_ICRNL(tty))
+   c = '\n';
+   } else if (c == '\n' && I_INLCR(tty))
+   c = '\r';
+
if (tty->icanon) {
if (c == ERASE_CHAR(tty) || c == KILL_CHAR(tty) ||
(c == WERASE_CHAR(tty) && L_IEXTEN(tty))) {

[PATCH] x86: vSMP selection in config

[Yinghai Lu]

find out vSMP setting is going away in config after make oldconfig

vSMP need to PARAVIRT and PCI.
so move PARAVIRT out of if PARAVIRT_GUEST, and make vSMP select PCI instead of
depends on PCI

after patch vSMP could stick there.

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

Index: linux-2.6/arch/x86/Kconfig
===
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -330,8 +330,9 @@ config X86_RDC321X
 
 config X86_VSMP
bool "Support for ScaleMP vSMP"
-   depends on X86_64 && PCI
+   depends on X86_64
select PARAVIRT
+   select PCI
help
  Support for ScaleMP vSMP systems.  Say 'Y' here if this kernel is
  supposed to run on these EM64T-based machines.  Only choose this 
option
@@ -376,6 +377,8 @@ config VMI
 
 source "arch/x86/lguest/Kconfig"
 
+endif
+
 config PARAVIRT
bool "Enable paravirtualization code"
depends on !(X86_VISWS || X86_VOYAGER)
@@ -385,8 +388,6 @@ config PARAVIRT
  over full virtualization.  However, when run without a hypervisor
  the kernel is theoretically slower and slightly larger.
 
-endif
-
 config ACPI_SRAT
def_bool y
depends on X86_32 && ACPI && NUMA && (X86_SUMMIT || X86_GENERICARCH)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Feb 24

[Stephen Rothwell]

Hi all,

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
allmodconfig for both powerpc and x86_64.

There were only two minor merge problems.

We are up to 33 trees, more are welcome (even if they are currently
empty).

Status of my local build tests is at
http://kisskb.ellerman.id.au/kisskb/branch/9/.

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


pgpNFchUXWFE1.pgp
Description: PGP signature

Re: [PATCH] cgroup: fix default notify_on_release setting

[Paul Menage]

On Sun, Feb 24, 2008 at 9:53 PM, Li Zefan <[EMAIL PROTECTED]> wrote:
> The documentation says the default value of notify_on_release of
>  a child cgroup is inherited from its parent, which is reasonable,
>  but the implementation just sets the flag disabled.
>
>  Signed-off-by: Li Zefan <[EMAIL PROTECTED]>

Acked-by: Paul Menage <[EMAIL PROTECTED]>

Yes, I guess it makes sense to follow the original cpusets behaviour.
I think that got lost when the notify-on-release functionality was
temporarily removed during cgroups development.

>  ---
>   kernel/cgroup.c |4 +++-
>   1 files changed, 3 insertions(+), 1 deletions(-)
>
>  diff --git a/kernel/cgroup.c b/kernel/cgroup.c
>  index d8abe99..e9c2fb0 100644
>  --- a/kernel/cgroup.c
>  +++ b/kernel/cgroup.c
>  @@ -2232,7 +2232,6 @@ static long cgroup_create(struct cgroup *parent, 
> struct dentry *dentry,
>
> mutex_lock(_mutex);
>
>  -   cgrp->flags = 0;
> INIT_LIST_HEAD(>sibling);
> INIT_LIST_HEAD(>children);
> INIT_LIST_HEAD(>css_sets);
>  @@ -2242,6 +2241,9 @@ static long cgroup_create(struct cgroup *parent, 
> struct dentry *dentry,
> cgrp->root = parent->root;
> cgrp->top_cgroup = parent->top_cgroup;
>
>  +   if (notify_on_release(parent))
>  +   set_bit(CGRP_NOTIFY_ON_RELEASE, >flags);
>  +
> for_each_subsys(root, ss) {
> struct cgroup_subsys_state *css = ss->create(ss, cgrp);
> if (IS_ERR(css)) {
>  --
>  1.5.4.rc3
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 [RT] 11/14] optimize the !printk fastpath through the lock acquisition

[Bill Huey (hui)]

[repost with all folks CCed]

On Sun, Feb 24, 2008 at 9:20 PM, Gregory Haskins
<[EMAIL PROTECTED]> wrote:
>  Are you saying that the modified logic that I introduced is broken?  Or
>  that the original use of the might_sleep() annotation inside this
>  function is broken?

It's probably safe to use, but it's not what its original purpose was
and you should use another function/macro. This is an annotation issue
and your use of it is inconsistent with how it's used in voluntary
preempt. I mentioned it before in a previous post. Folks will correct
me if I'm wrong but you should use another macro or function.

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

Re: [RFC] [PATCH] To refuse users from probing preempt_schedule()

[Dave Hansen]

On Mon, 2008-02-25 at 11:27 +0530, srinivasa wrote:
> This patch prohibits user from probing preempt_schedule(). One way of
> prohibiting the user from probing functions is by marking such 
> functions with __kprobes. But this method doesn't work for those functions,
> which are already marked to different section like preempt_schedule()
> (belongs to __sched section). So we use blacklist approach to refuse user
> from probing these functions.

preempt_schedule() does sound really, really important.  But, what kinds
of functions can't be kprobed?  It would be nice to give that blacklist
a nice comment on the topic. :)

Also, have you strained your brains to think of other functions that
this should be applied to?  Is it just for functions that are sensitive
and already have an assigned section?  Might be nice to call that out
explicitly.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bcm43xx regression in 2.6.24 (with patch)

[Pekka J Enberg]

Hi Michael,

On Sun, 24 Feb 2008, Michael Buesch wrote:
> > The ony way I see this was possible, you manually changed the
> > module loading order, so that the b43xx module was loaded prior
> > to the ssb and b44 modules. Right?
> 
> Right. So "so I'm left with either no wifi or no ethenet" being wrong.

Lets make this simple: it used to work before and now it doesn't. 
Therefore it's a regression that must be addressed. Period.

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] a new example to use kobject/kobj_attribute (final#2)

[Kohei KaiGai]

[PATCH 3/3] a new example to use kobject/kobj_attribute

This patch can provide a new exmple to use kobject and attribute.
The _show() and _store() method can refer/store the private data field of
kobj_attribute structure to know what entries are accessed by users.
It will make easier to share a single _show()/_store() method with several
entries.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 samples/kobject/kobject-example.c |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/samples/kobject/kobject-example.c 
b/samples/kobject/kobject-example.c
index 08d0d3f..5486a14 100644
--- a/samples/kobject/kobject-example.c
+++ b/samples/kobject/kobject-example.c
@@ -77,6 +77,35 @@ static struct kobj_attribute baz_attribute =
 static struct kobj_attribute bar_attribute =
__ATTR(bar, 0666, b_show, b_store);

+/*
+ * You can store a private data within 'data' field of kobj_attribute.
+ * It enables to share a single _show() or _store() method with several
+ * entries.
+ */
+static ssize_t integer_show(struct kobject *kobj,
+   struct kobj_attribute *attr,
+   char *buf)
+{
+   return scnprintf(buf, PAGE_SIZE, "%ld\n", (long) attr->data);
+}
+
+static ssize_t integer_store(struct kobject *kobj,
+struct kobj_attribute *attr,
+const char *buf, size_t count)
+{
+   long code;
+
+   sscanf(buf, "%ld", );
+   attr->data = (void *) code;
+   return count;
+}
+
+static struct kobj_attribute hoge_attribute =
+   __ATTR_DATA(hoge, 0666, integer_show, integer_store, (long) 123);
+static struct kobj_attribute piyo_attribute =
+   __ATTR_DATA(piyo, 0666, integer_show, integer_store, (long) 456);
+static struct kobj_attribute fuga_attribute =
+   __ATTR_DATA(fuga, 0444, integer_show, NULL, (long) 789);

 /*
  * Create a group of attributes so that we can create and destory them all
@@ -86,6 +115,9 @@ static struct attribute *attrs[] = {
_attribute.attr,
_attribute.attr,
_attribute.attr,
+   _attribute.attr,
+   _attribute.attr,
+   _attribute.attr,
NULL,   /* need to NULL terminate the list of attributes */
 };

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] exporting capability name/code pairs (final#2)

[Kohei KaiGai]

[PATCH 2/3] exporting capability name/code pairs

This patch enables to export code/name pairs of capabilities the running
kernel supported.

A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
at 2.6.25. However, we have no interface to disclose what capabilities
are supported on the running kernel. Thus, we have to maintain libcap
version in appropriate one synchronously.

This patch enables libcap to collect the list of capabilities at run time,
and provide them for users. It helps to improve portability of library.

It exports these information as regular files under /sys/kernel/capability.
The numeric node exports its name, the symbolic node exports its code.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 Documentation/ABI/testing/sysfs-kernel-capability |   23 +
 scripts/mkcapnames.sh |   44 +
 security/Makefile |9 ++
 security/commoncap.c  |   99 +
 4 files changed, 175 insertions(+), 0 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-kernel-capability 
b/Documentation/ABI/testing/sysfs-kernel-capability
index e69de29..d4a14e7 100644
--- a/Documentation/ABI/testing/sysfs-kernel-capability
+++ b/Documentation/ABI/testing/sysfs-kernel-capability
@@ -0,0 +1,23 @@
+What:  /sys/kernel/capability
+Date:  Feb 2008
+Contact:   KaiGai Kohei <[EMAIL PROTECTED]>
+Description:
+   The entries under /sys/kernel/capability are used to export
+   the list of capabilities the running kernel supports.
+
+   - /sys/kernel/capability/version
+ returns the most preferable version number for the
+ running kernel.
+ e.g) $ cat /sys/kernel/capability/version
+  0x20071026
+
+   - /sys/kernel/capability/code/
+ returns its symbolic representation, on reading.
+ e.g) $ cat /sys/kernel/capability/codes/30
+  cap_audit_control
+
+   - /sys/kernel/capability/name/
+ returns its numerical representation, on reading.
+ e.g) $ cat /sys/kernel/capability/names/cap_sys_pacct
+  20
+
diff --git a/scripts/mkcapnames.sh b/scripts/mkcapnames.sh
index e69de29..5d36d52 100644
--- a/scripts/mkcapnames.sh
+++ b/scripts/mkcapnames.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+#
+# generate a cap_names.h file from include/linux/capability.h
+#
+
+CAPHEAD="`dirname $0`/../include/linux/capability.h"
+REGEXP='^#define CAP_[A-Z_]+[  ]+[0-9]+$'
+NUMCAP=`cat "$CAPHEAD" | egrep -c "$REGEXP"`
+
+echo '#ifndef CAP_NAMES_H'
+echo '#define CAP_NAMES_H'
+echo
+echo '/*'
+echo ' * Do NOT edit this file directly.'
+echo ' * This file is generated from include/linux/capability.h automatically'
+echo ' */'
+echo
+echo '#if !defined(SYSFS_CAP_NAME_ENTRY) || !defined(SYSFS_CAP_CODE_ENTRY)'
+echo '#error cap_names.h should be included from security/capability.c'
+echo '#else'
+echo "#if $NUMCAP != CAP_LAST_CAP + 1"
+echo '#error mkcapnames.sh cannot collect capabilities correctly'
+echo '#else'
+cat "$CAPHEAD" | egrep "$REGEXP" \
+| awk '{ printf("SYSFS_CAP_NAME_ENTRY(%s,%s);\n", tolower($2), $2); }'
+echo
+echo 'static struct attribute *capability_name_attrs[] = {'
+cat "$CAPHEAD" | egrep "$REGEXP" \
+| awk '{ printf("\t&%s_name_attr.attr,\n", tolower($2)); } END { print 
"\tNULL," }'
+echo '};'
+
+echo
+cat "$CAPHEAD" | egrep "$REGEXP" \
+| awk '{ printf("SYSFS_CAP_CODE_ENTRY(%s,%s);\n", tolower($2), $2); }'
+echo
+echo 'static struct attribute *capability_code_attrs[] = {'
+cat "$CAPHEAD" | egrep "$REGEXP" \
+| awk '{ printf("\t&%s_code_attr.attr,\n", tolower($2)); } END { print 
"\tNULL," }'
+echo '};'
+
+echo '#endif'
+echo '#endif'
+echo '#endif'
diff --git a/security/Makefile b/security/Makefile
index 9e8b025..4093e3e 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -18,3 +18,12 @@ obj-$(CONFIG_SECURITY_SELINUX)   += 
selinux/built-in.o
 obj-$(CONFIG_SECURITY_SMACK)   += commoncap.o smack/built-in.o
 obj-$(CONFIG_SECURITY_CAPABILITIES)+= commoncap.o capability.o
 obj-$(CONFIG_SECURITY_ROOTPLUG)+= commoncap.o root_plug.o
+
+# cap_names.h contains the code/name pair of capabilities.
+# It is generated using include/linux/capability.h automatically.
+$(obj)/commoncap.o: $(obj)/cap_names.h
+quiet_cmd_cap_names  = CAPS$@
+   cmd_cap_names  = /bin/sh $(srctree)/scripts/mkcapnames.sh > $@
+targets += cap_names.h
+$(obj)/cap_names.h: $(srctree)/scripts/mkcapnames.sh 
$(srctree)/include/linux/capability.h FORCE
+   $(call if_changed,cap_names)
diff --git a/security/commoncap.c b/security/commoncap.c
index 5aba826..9483fa9 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 /* Global security state */

@@ -637,3 

[PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[Kohei KaiGai]

[PATCH 1/3] add a private data field within kobj_attribute structure.

This patch add a private data field, declared as void *, within kobj_attribute
structure. The _show() and _store() method in the sysfs attribute entries can
refer this information to identify what entry is accessed.
It makes easier to share a single method implementation with several similar
entries, like ones to export the list of capabilities the running kernel
supports.

Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
--
 Documentation/kobject.txt |6 ++
 include/linux/kobject.h   |1 +
 include/linux/sysfs.h |7 +++
 3 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
index bf3256e..efa5d71 100644
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt
@@ -207,6 +207,12 @@ Both types of attributes used here, with a kobject that 
has been created
 with the kobject_create_and_add(), can be of type kobj_attribute, so no
 special custom attribute is needed to be created.

+The simple kobj_attribute is prototyped at include/linux/kobject.h, and can
+contain your own show()/store() method and private data.
+When an attribute is accessed, these methods are invoked with kobject,
+kobj_attribute and read/write buffer. The method can refer the private data
+via given kobj_attribute, to show/store itself in the text representation.
+
 See the example module, samples/kobject/kobject-example.c for an
 implementation of a simple kobject and attributes.

diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index caa3f41..57d5bf1 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -130,6 +130,7 @@ struct kobj_attribute {
char *buf);
ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
 const char *buf, size_t count);
+   void *data; /* a private field */
 };

 extern struct sysfs_ops kobj_sysfs_ops;
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 8027104..6f40ff9 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -50,6 +50,13 @@ struct attribute_group {
.store  = _store,   \
 }

+#define __ATTR_DATA(_name,_mode,_show,_store,_data) {  \
+   .attr = {.name = __stringify(_name), .mode = _mode },   \
+   .show   = _show,\
+   .store  = _store,   \
+   .data   = (void *)(_data),  \
+}
+   
 #define __ATTR_RO(_name) { \
.attr   = { .name = __stringify(_name), .mode = 0444 }, \
.show   = _name##_show, \

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] exporting capability name/code pairs (final#2)

[Kohei KaiGai]

The following three patches enables to export code/name pairs of
capabilities the running kernel supports, and add a documentation
and samples to use this feature.

[PATCH 1/3] add a private data field within kobj_attribute structure.

This patch add a private data field, declared as void *, within kobj_attribute
structure. The _show() and _store() method in the sysfs attribute entries can
refer this information to identify what entry is accessed.
It makes easier to share a single method implementation with several similar
entries, like ones to export the list of capabilities the running kernel
supports.

[PATCH 2/3] exporting capability name/code pairs

This patch enables to export code/name pairs of capabilities the running
kernel supported.

A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
at 2.6.25. However, we have no interface to disclose what capabilities
are supported on the running kernel. Thus, we have to maintain libcap
version in appropriate one synchronously.

This patch enables libcap to collect the list of capabilities at run time,
and provide them for users. It helps to improve portability of library.

It exports these information as regular files under /sys/kernel/capability.
The numeric node exports its name, the symbolic node exports its code.

[PATCH 3/3] a new example to use kobject/kobj_attribute

This patch can provide a new exmple to use kobject and attribute.
The _show() and _store() method can refer/store the private data field of
kobj_attribute structure to know what entries are accessed by users.
It will make easier to share a single _show()/_store() method with several
entries.

o changes from the previous version
 - add a short description at Documentation/kobject.txt, to use private
   member within kobj_attribute.
 - "supported" is replaced with "supports" at sysfs-kernel-capability.
 - "$(src)/../" is replaced with "$(srctree)/" at security/Makefile
 - The private member is casted to long, when it stores integer value.

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

Re: IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Brad Rosser]

Hi Boris,

>  Well, this sounds strange. Are you sure you're entering the boot options
>  correctly on the kernel command line? Which is your boot loader? I just 
> booted
>  my machine with 'hdc=noprobe'  (hdc is my cdrom drive) and here's what i get:
>
>  ...
>  [0.304774] Probing IDE interface ide0...
>  [0.569359] hdb: SAMSUNG SP2014N, ATA DISK drive
>  [0.613977] Switched to NOHz mode on CPU #1
>  [0.773368] Switched to NOHz mode on CPU #0
>  [0.874486] hda: QUANTUM FIREBALLlct10 20, ATA DISK drive
>  [0.874506] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
>  [0.874506] hda: drive side 80-wire cable detection failed, limiting max 
> speed to UDMA33
>  [0.874506] hda: UDMA/33 mode selected
>  [0.874533] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
>  [0.874620] hdb: UDMA/100 mode selected
>  [0.874744] Probing IDE interface ide1...

>  so it seems you should check whether your kernel is receiving the 
> 'hda=noprobe'
>  boot option at all, or something along that path is going wrong...

I'm entering the option 'hda=noprobe' (as one example) right after my boot
label in LILO.  The dmesg output I attached last time was a boot of straight
2.6.25-rc2 without any options; I've attached 'dmesg.noprobe.out' which is
the result of a boot with 'hda=noprobe'.

I must have done something stupid, but I can't see what; if you look at this
line from the dmesg output:

Kernel command line: BOOT_IMAGE=linux_2.6.25rc2 ro root=900
md=0,/dev/sda5,/dev/sdb5 hda=noprobe

... it would suggest the option 'hda=noprobe' was entered correctly?

>  > I tried to apply the patch but failed; I probably did something wrong.
>  > I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c'
>  > and ran 'patch --dry-run -b -p1 < ../bart_patch'.  This is part of my 
> script
>  > log:
>
>  are you sure you're _really_ using 2.6.25-rc2? Applying the patch against 
> that
>  kernel works just fine, no fuzziness or even rejects. Care to try out on a 
> fresh
>  kernel source tarball? After all, building a kernel with your quad core cpu 
> won't
>  take that long :-) when using make -j8 or something in that order.

Heh.  This is my first new machine in 8 years, and I couldn't wait to start
using multiple cores.  I was quick to discover the '-j' option ... but I only
do '-j 4'.  Anyway ... I'd downloaded the full baseline linux-2.6.24.tar.bz2,
unpacked it, and then ran the patch patch-2.6.25-rc2.bz2 against it.  That
patch ran perfectly.  And I was in the right directory when I ran Bart's patch,
as I listed in my earlier e-mail!  All indications were that I was running the
2.6.25-rc2 kernel as required, I thought.

Well, I see that rc3 is out; maybe I'll give that a shot.


Brad


dmesg.noprobe.out
Description: Binary data

[RFC] [PATCH] To refuse users from probing preempt_schedule()

[srinivasa]

From: Srinivasa Ds <[EMAIL PROTECTED]>

This patch prohibits user from probing preempt_schedule(). One way of
prohibiting the user from probing functions is by marking such 
functions with __kprobes. But this method doesn't work for those functions,
which are already marked to different section like preempt_schedule()
(belongs to __sched section). So we use blacklist approach to refuse user
from probing these functions.

In blacklist approach we populate the blacklisted function's starting
address and its size in kprobe_blacklist structure. Then we verify the user
specified address against start and end of the blacklisted function.
So any attempt to register probe on blacklisted functions will be rejected.

please let me know your comments.

Signed-off-by: Srinivasa DS <[EMAIL PROTECTED]> 
Signed-off-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
Signed-off-by: Jim Keniston <[EMAIL PROTECTED]> 


---
 include/linux/kprobes.h |7 ++
 kernel/kprobes.c|   52 

 2 files changed, 59 insertions(+)

Index: linux-2.6.25-rc3/include/linux/kprobes.h
===
--- linux-2.6.25-rc3.orig/include/linux/kprobes.h
+++ linux-2.6.25-rc3/include/linux/kprobes.h
@@ -173,6 +173,13 @@ struct kretprobe_blackpoint {
const char *name;
void *addr;
 };
+
+struct kprobe_blackpoint {
+   const char *name;
+   unsigned long start_addr;
+   unsigned long range;
+};
+
 extern struct kretprobe_blackpoint kretprobe_blacklist[];
 
 static inline void kretprobe_assert(struct kretprobe_instance *ri,
Index: linux-2.6.25-rc3/kernel/kprobes.c
===
--- linux-2.6.25-rc3.orig/kernel/kprobes.c
+++ linux-2.6.25-rc3/kernel/kprobes.c
@@ -89,6 +89,18 @@ struct kprobe_insn_page {
int ngarbage;
 };
 
+/*
+ * Normally, functions that we'd want to prohibit kprobes in, are marked
+ * __kprobes. But, there are cases where such functions already belong to
+ * a different section (__sched for preempt_schedule)
+ *
+ * For such cases, we now have a blacklist
+ */
+struct kprobe_blackpoint kprobe_blacklist[] = {
+{"preempt_schedule",},
+{NULL}/* Terminator */
+};
+
 enum kprobe_slot_state {
SLOT_CLEAN = 0,
SLOT_DIRTY = 1,
@@ -492,9 +504,22 @@ static int __kprobes register_aggr_kprob
 
 static int __kprobes in_kprobes_functions(unsigned long addr)
 {
+   struct kprobe_blackpoint *kb;
+
if (addr >= (unsigned long)__kprobes_text_start &&
addr < (unsigned long)__kprobes_text_end)
return -EINVAL;
+   /*
+* If there exists a kprobe_blacklist, verify and
+* fail any probe registration in the prohibited area
+*/
+   for (kb = kprobe_blacklist; kb->name != NULL; kb++) {
+   if (kb->start_addr) {
+   if (addr >= kb->start_addr &&
+   addr < (kb->start_addr + kb->range))
+   return -EINVAL;
+   }
+   }
return 0;
 }
 
@@ -805,6 +830,11 @@ void __kprobes unregister_kretprobe(stru
 static int __init init_kprobes(void)
 {
int i, err = 0;
+   unsigned long offset = 0, size = 0;
+   char *modname, namebuf[128];
+   const char *symbol_name;
+   void *addr;
+   struct kprobe_blackpoint *kb;
 
/* FIXME allocate the probe table, currently defined statically */
/* initialize all list heads */
@@ -813,6 +843,28 @@ static int __init init_kprobes(void)
INIT_HLIST_HEAD(_inst_table[i]);
}
 
+   /*
+* Lookup and populate the kprobe_blacklist.
+*
+* Unlike the kretprobe blacklist, we'll need to determine
+* the range of addresses that belong to the said functions,
+* since a kprobe need not necessarily be at the beginning
+* of a function.
+*/
+   for (kb = kprobe_blacklist; kb->name != NULL; kb++) {
+   kprobe_lookup_name(kb->name, addr);
+   if (!addr)
+   continue;
+
+   kb->start_addr = (unsigned long)addr;
+   symbol_name = kallsyms_lookup(kb->start_addr,
+   , , , namebuf);
+   if (!symbol_name)
+   kb->range = 0;
+   else
+   kb->range = size;
+   }
+
if (kretprobe_blacklist_size) {
/* lookup the function address from its name */
for (i = 0; kretprobe_blacklist[i].name != NULL; i++) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] Kprobes: Move kprobe examples to samples/

[Ananth N Mavinakayanahalli]

From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>

Move kprobes examples from Documentation/kprobes.txt to under samples/.
Patch originally by Randy Dunlap.

o Updated the patch to apply on 2.6.25-rc3
o Modified examples code to build on multiple architectures. Currently,
  the kprobe and jprobe examples code works for x86 and powerpc
o Cleaned up unneeded #includes
o Cleaned up Kconfig per Sam Ravnborg's suggestions to fix build break
  on archs that don't have kretprobes
o Implemented suggestions by Mathieu Desnoyers on CONFIG_KRETPROBES
o Included Andrew Morton's cleanup based on x86-git
o Modified kretprobe_example to act as a arch-agnostic module to
  determine routine execution times:
Use 'modprobe kretprobe_example func=' to determine
execution time of func_name in nanoseconds.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Acked-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
 Documentation/kprobes.txt   |  243 
 samples/Kconfig |   11 +
 samples/Makefile|2 
 samples/kprobes/Makefile|5 
 samples/kprobes/jprobe_example.c|   68 ++
 samples/kprobes/kprobe_example.c|   91 +
 samples/kprobes/kretprobe_example.c |  106 +++
 7 files changed, 287 insertions(+), 239 deletions(-)

Index: linux-2.6.25-rc2/Documentation/kprobes.txt
===
--- linux-2.6.25-rc2.orig/Documentation/kprobes.txt
+++ linux-2.6.25-rc2/Documentation/kprobes.txt
@@ -192,7 +192,8 @@ code mapping.
 The Kprobes API includes a "register" function and an "unregister"
 function for each type of probe.  Here are terse, mini-man-page
 specifications for these functions and the associated probe handlers
-that you'll write.  See the latter half of this document for examples.
+that you'll write.  See the files in the samples/kprobes/ sub-directory
+for examples.
 
 4.1 register_kprobe
 
@@ -420,249 +421,15 @@ e. Watchpoint probes (which fire on data
 
 8. Kprobes Example
 
-Here's a sample kernel module showing the use of kprobes to dump a
-stack trace and selected i386 registers when do_fork() is called.
-- cut here -
-/*kprobe_example.c*/
-#include 
-#include 
-#include 
-#include 
-
-/*For each probe you need to allocate a kprobe structure*/
-static struct kprobe kp;
-
-/*kprobe pre_handler: called just before the probed instruction is executed*/
-int handler_pre(struct kprobe *p, struct pt_regs *regs)
-{
-   printk("pre_handler: p->addr=0x%p, eip=%lx, eflags=0x%lx\n",
-   p->addr, regs->eip, regs->eflags);
-   dump_stack();
-   return 0;
-}
-
-/*kprobe post_handler: called after the probed instruction is executed*/
-void handler_post(struct kprobe *p, struct pt_regs *regs, unsigned long flags)
-{
-   printk("post_handler: p->addr=0x%p, eflags=0x%lx\n",
-   p->addr, regs->eflags);
-}
-
-/* fault_handler: this is called if an exception is generated for any
- * instruction within the pre- or post-handler, or when Kprobes
- * single-steps the probed instruction.
- */
-int handler_fault(struct kprobe *p, struct pt_regs *regs, int trapnr)
-{
-   printk("fault_handler: p->addr=0x%p, trap #%dn",
-   p->addr, trapnr);
-   /* Return 0 because we don't handle the fault. */
-   return 0;
-}
-
-static int __init kprobe_init(void)
-{
-   int ret;
-   kp.pre_handler = handler_pre;
-   kp.post_handler = handler_post;
-   kp.fault_handler = handler_fault;
-   kp.symbol_name = "do_fork";
-
-   ret = register_kprobe();
-   if (ret < 0) {
-   printk("register_kprobe failed, returned %d\n", ret);
-   return ret;
-   }
-   printk("kprobe registered\n");
-   return 0;
-}
-
-static void __exit kprobe_exit(void)
-{
-   unregister_kprobe();
-   printk("kprobe unregistered\n");
-}
-
-module_init(kprobe_init)
-module_exit(kprobe_exit)
-MODULE_LICENSE("GPL");
-- cut here -
-
-You can build the kernel module, kprobe-example.ko, using the following
-Makefile:
-- cut here -
-obj-m := kprobe-example.o
-KDIR := /lib/modules/$(shell uname -r)/build
-PWD := $(shell pwd)
-default:
-   $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
-clean:
-   rm -f *.mod.c *.ko *.o
-- cut here -
-
-$ make
-$ su -
-...
-# insmod kprobe-example.ko
-
-You will see the trace data in /var/log/messages and on the console
-whenever do_fork() is invoked to create a new process.
+See samples/kprobes/kprobe_example.c
 
 9. Jprobes Example
 
-Here's a sample kernel module showing the use of jprobes to dump
-the arguments of do_fork().
-- cut here -
-/*jprobe-example.c */
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/*
- * Jumper probe for do_fork.
- * Mirror principle enables access to 

[PATCH 1/2] Kprobes: Indicate kretprobe support in Kconfig

[Ananth N Mavinakayanahalli]

From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>

This patch adds CONFIG_HAVE_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.

Updated to apply on 2.6.25-rc3. Thanks to Sam Ravnborg for helping
make the patch more lean.

Per Mathieu's suggestion, added CONFIG_KRETPROBES and fixed up
dependencies.

Signed-off-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
Acked-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
 arch/Kconfig  |7 +++
 arch/arm/Kconfig  |1 +
 arch/ia64/Kconfig |1 +
 arch/powerpc/Kconfig  |1 +
 arch/s390/Kconfig |1 +
 arch/sparc64/Kconfig  |1 +
 arch/x86/Kconfig  |1 +
 include/asm-arm/kprobes.h |1 -
 include/asm-ia64/kprobes.h|1 -
 include/asm-powerpc/kprobes.h |1 -
 include/asm-s390/kprobes.h|1 -
 include/asm-sparc64/kprobes.h |2 --
 include/asm-x86/kprobes.h |1 -
 include/linux/kprobes.h   |6 +++---
 kernel/kprobes.c  |9 +++--
 15 files changed, 19 insertions(+), 16 deletions(-)

Index: linux-2.6.25-rc2/arch/Kconfig
===
--- linux-2.6.25-rc2.orig/arch/Kconfig
+++ linux-2.6.25-rc2/arch/Kconfig
@@ -27,5 +27,12 @@ config KPROBES
  for kernel debugging, non-intrusive instrumentation and testing.
  If in doubt, say "N".
 
+config KRETPROBES
+   def_bool y
+   depends on KPROBES && HAVE_KRETPROBES
+
 config HAVE_KPROBES
def_bool n
+
+config HAVE_KRETPROBES
+   def_bool n
Index: linux-2.6.25-rc2/arch/ia64/Kconfig
===
--- linux-2.6.25-rc2.orig/arch/ia64/Kconfig
+++ linux-2.6.25-rc2/arch/ia64/Kconfig
@@ -18,6 +18,7 @@ config IA64
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_KPROBES
+   select HAVE_KRETPROBES
default y
help
  The Itanium Processor Family is Intel's 64-bit successor to
Index: linux-2.6.25-rc2/arch/powerpc/Kconfig
===
--- linux-2.6.25-rc2.orig/arch/powerpc/Kconfig
+++ linux-2.6.25-rc2/arch/powerpc/Kconfig
@@ -90,6 +90,7 @@ config PPC
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_KPROBES
+   select HAVE_KRETPROBES
 
 config EARLY_PRINTK
bool
Index: linux-2.6.25-rc2/arch/x86/Kconfig
===
--- linux-2.6.25-rc2.orig/arch/x86/Kconfig
+++ linux-2.6.25-rc2/arch/x86/Kconfig
@@ -21,6 +21,7 @@ config X86
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_KPROBES
+   select HAVE_KRETPROBES
select HAVE_KVM
 
 
Index: linux-2.6.25-rc2/include/asm-ia64/kprobes.h
===
--- linux-2.6.25-rc2.orig/include/asm-ia64/kprobes.h
+++ linux-2.6.25-rc2/include/asm-ia64/kprobes.h
@@ -82,7 +82,6 @@ struct kprobe_ctlblk {
struct prev_kprobe prev_kprobe[ARCH_PREV_KPROBE_SZ];
 };
 
-#define ARCH_SUPPORTS_KRETPROBES
 #define kretprobe_blacklist_size 0
 
 #define SLOT0_OPCODE_SHIFT (37)
Index: linux-2.6.25-rc2/include/asm-powerpc/kprobes.h
===
--- linux-2.6.25-rc2.orig/include/asm-powerpc/kprobes.h
+++ linux-2.6.25-rc2/include/asm-powerpc/kprobes.h
@@ -80,7 +80,6 @@ typedef unsigned int kprobe_opcode_t;
 #define is_trap(instr) (IS_TW(instr) || IS_TWI(instr))
 #endif
 
-#define ARCH_SUPPORTS_KRETPROBES
 #define flush_insn_slot(p) do { } while (0)
 #define kretprobe_blacklist_size 0
 
Index: linux-2.6.25-rc2/include/asm-x86/kprobes.h
===
--- linux-2.6.25-rc2.orig/include/asm-x86/kprobes.h
+++ linux-2.6.25-rc2/include/asm-x86/kprobes.h
@@ -42,7 +42,6 @@ typedef u8 kprobe_opcode_t;
: (((unsigned long)current_thread_info()) + THREAD_SIZE \
   - (unsigned long)(ADDR)))
 
-#define ARCH_SUPPORTS_KRETPROBES
 #define flush_insn_slot(p) do { } while (0)
 
 extern const int kretprobe_blacklist_size;
Index: linux-2.6.25-rc2/include/linux/kprobes.h
===
--- linux-2.6.25-rc2.orig/include/linux/kprobes.h
+++ linux-2.6.25-rc2/include/linux/kprobes.h
@@ -125,11 +125,11 @@ struct jprobe {
 DECLARE_PER_CPU(struct kprobe *, current_kprobe);
 DECLARE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
 
-#ifdef ARCH_SUPPORTS_KRETPROBES
+#ifdef CONFIG_KRETPROBES
 extern void arch_prepare_kretprobe(struct kretprobe_instance *ri,
   struct pt_regs *regs);
 extern int arch_trampoline_kprobe(struct kprobe *p);
-#else /* ARCH_SUPPORTS_KRETPROBES */
+#else /* 

[PATCH] cgroup: fix default notify_on_release setting

[Li Zefan]

The documentation says the default value of notify_on_release of
a child cgroup is inherited from its parent, which is reasonable,
but the implementation just sets the flag disabled.

Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
 kernel/cgroup.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d8abe99..e9c2fb0 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2232,7 +2232,6 @@ static long cgroup_create(struct cgroup *parent, struct 
dentry *dentry,
 
mutex_lock(_mutex);
 
-   cgrp->flags = 0;
INIT_LIST_HEAD(>sibling);
INIT_LIST_HEAD(>children);
INIT_LIST_HEAD(>css_sets);
@@ -2242,6 +2241,9 @@ static long cgroup_create(struct cgroup *parent, struct 
dentry *dentry,
cgrp->root = parent->root;
cgrp->top_cgroup = parent->top_cgroup;
 
+   if (notify_on_release(parent))
+   set_bit(CGRP_NOTIFY_ON_RELEASE, >flags);
+
for_each_subsys(root, ss) {
struct cgroup_subsys_state *css = ss->create(ss, cgrp);
if (IS_ERR(css)) {
-- 
1.5.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Change a WARN message in checkpatch

[Benny Halevy]

On Feb. 24, 2008, 19:29 -0800, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 24, 2008 at 07:14:13PM +0100, Paolo Ciarrocchi wrote:
>> On Sun, Feb 24, 2008 at 4:18 PM, Benny Halevy <[EMAIL PROTECTED]> wrote:
>> [...]
>>>  How about:
>>>  -   WARN("no space between function name and 
>>> open parenthesis '('\n" . $herecurr);
>>>  +   WARN("there should be no space between 
>>> function name and open parenthesis '('\n" . $herecurr);
>> I originally suggested:
>> +   WARN("don't put a space between
>> function name and open parenthesis '('\n" . $herecurr);
>> but I really prefer your version.
>>
>>>  The original phrasing can be interpreted like "there is no space between 
>>> ..." and the correct
>>>  interpretation should be "there should be no space between ..."
>> Indeed.
> 
> As we want the messages to be as short as possible, I am leaning towards
> standardising on:
> 
>   spaces prohibited 
>   spaces required 

Sounds good to me.

Benny

> 
> -apw

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86_64: make amd quad core 8 socket system not be clustered_box v2

[Yinghai Lu]

On Sun, Feb 24, 2008 at 4:29 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
>  >
>  > quad core 8 socket system will have apic id lifting.the apic id range could
>  > be [4, 0x23]. and apic_is_clustered_box will think that need to three 
> clusters
>  > and that is large than 2. So it is treated as clustered_box.
>
>  Ok I see you chose the quick hack over doing it properly ...

you didn't answer my question:

for IBM Summit2, Unisys ES7000, and ScaleMP vSMP,
if call cpus sockets are fully populated with quadcore cpus, do they
still have hole between apic id?

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Borislav Petkov]

On Mon, Feb 25, 2008 at 11:58:57AM +1000, Brad Rosser wrote:
> On Mon, Feb 25, 2008 at 3:34 AM, Borislav Petkov
> <[EMAIL PROTECTED]> wrote:
> > On Sun, Feb 24, 2008 at 03:38:34PM +1000, Brad Rosser wrote:
> > >
> > > There's nothing in the bios that allows me to move one away from
> > > the other.  I can 'reserve' or block IRQs, but that only shifts them
> > > both to another interrupt.
> >
> >  well the driver probes the bios for that data and assigns the irq line it 
> > gets
> >  from it.
> 
> Oh.  I thought from all the 'IRQ routing/balancing' and the like in the
> kernel there might be a way to switch things around, give the
> Realtek driver a different IRQ than the one being used by the ide driver.
> Just my crossed-fingers hope.
> 
> >  Can you please send me your whole boot log of 2.6.25-rc2? Thanks.
> 
> It's attached as file 'dmesg.bug.out'.
> 
> >  since your cdrom seems to be hda from what i've seen above, try booting 
> > with
> >  'hda=noprobe' or maybe 'hda=none' to see which one turns the probing off 
> > for
> >  you. See Documentation/ide.txt for details.
> 
> I tried both options, but in both cases there was no difference; the 
> ide_cd_mod
> module was still loaded and the 'confused' message still popped up.
> 
> I did four boots/tests of the 2.6.25-rc2 kernel, with and without those
> boot parameters ... on all four I had the 'confused' message several times:
> 
> hda: cdrom_newpc_intr: The drive appears confused (ireason = 0x01).
> Trying to recover by ending request.

Well, this sounds strange. Are you sure you're entering the boot options
correctly on the kernel command line? Which is your boot loader? I just booted
my machine with 'hdc=noprobe'  (hdc is my cdrom drive) and here's what i get:

...
[0.304774] Probing IDE interface ide0...
[0.569359] hdb: SAMSUNG SP2014N, ATA DISK drive
[0.613977] Switched to NOHz mode on CPU #1
[0.773368] Switched to NOHz mode on CPU #0
[0.874486] hda: QUANTUM FIREBALLlct10 20, ATA DISK drive
[0.874506] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[0.874506] hda: drive side 80-wire cable detection failed, limiting max 
speed to UDMA33
[0.874506] hda: UDMA/33 mode selected
[0.874533] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[0.874620] hdb: UDMA/100 mode selected
[0.874744] Probing IDE interface ide1...
-->
[0.877750] hdc: ide_wait_not_busy() skipped
-->
[1.136180] hdd: IC35L120AVV207-0, ATA DISK drive
[1.186959] hdd: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[1.186959] hdd: host side 80-wire cable detection failed, limiting max 
speed to UDMA33
[1.186959] hdd: UDMA/33 mode selected
[1.186959] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[1.194971] ide1 at 0x170-0x177,0x376 on irq 15
[1.206876] Probing IDE interface ide2...
[1.720661] Probing IDE interface ide3...
[2.233564] Probing IDE interface ide4...
[2.746462] Probing IDE interface ide5...
[3.259395] hda: max request size: 128KiB
[3.259571] hda: 39876480 sectors (20416 MB) w/418KiB Cache, CHS=39560/16/63
[3.259571] hda: cache flushes not supported
[3.259571]  hda: hda1 hda2 hda3
[3.269291] hdb: max request size: 512KiB
[3.269511] hdb: 390721968 sectors (200049 MB) w/8192KiB Cache, 
CHS=24321/255/63
[3.269962] hdb: cache flushes supported
[3.270078]  hdb: hdb1
[3.280914] hdd: max request size: 512KiB
[3.281247] hdd: 241254720 sectors (123522 MB) w/1821KiB Cache, 
CHS=16383/255/63
[3.281729] hdd: cache flushes supported
[3.281729]  hdd: hdd1
[3.296760] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 
irq 1,12
...

so it seems you should check whether your kernel is receiving the 'hda=noprobe'
boot option at all, or something along that path is going wrong...

[...]

> I tried to apply the patch but failed; I probably did something wrong.
> I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c'
> and ran 'patch --dry-run -b -p1 < ../bart_patch'.  This is part of my script
> log:
> 
> root:/usr/src/linux-2.6.25-rc2# pwd
> /usr/src/linux-2.6.25-rc2
> root:/usr/src/linux-2.6.25-rc2# cat ../bart_patch
> Index: b/drivers/ide/ide-cd.c
> ===
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -670,8 +670,8 @@ static void cdrom_buffer_sectors (ide_dr
>  * and attempt to recover if there are problems.  Returns  0 if everything's
> ...
> ...
> root:/usr/src/linux-2.6.25-rc2# patch --dry-run -b -p1 < ../bart_patch
> patching file drivers/ide/ide-cd.c
> Hunk #1 FAILED at 670.
> Hunk #2 FAILED at 701.
> Hunk #3 FAILED at 1074.
> Hunk #4 FAILED at 1104.
> 4 out of 4 hunks FAILED -- saving rejects to file drivers/ide/ide-cd.c.rej
> 
> Since it found drivers/ide/ide-cd.c I guess I got the '-p' level right (?),
> and that's about the sum total of my 'patch' experience to date.
> Sorry.  Can you tell me what I did wrong?

are you sure 

Re: [PATCH] maple: fix device detection

[Paul Mundt]

On Sun, Feb 24, 2008 at 10:32:53PM +, Adrian McMenamin wrote:
> On Sun, 2008-02-24 at 21:50 +, Adrian McMenamin wrote:
> > On Sun, 2008-02-24 at 14:30 +, Adrian McMenamin wrote:
> > > The maple bus driver that went into the kernel mainline in
> > > September 2007 contained some bugs which were revealed by the
> > > update of the kobj code for the current release series.
> > > Unfortunately those bugs also helped ensure maple devices were
> > > properly detected. This patch (against the current git) now ensures
> > > that devices are properly detected again.
> > > 
> > 
> > Further testing has shown this has introduced another bug, this time
> > limiting the effectiveness of subdevice detection. Please ignore this
> > while I work on a fix.
> > 
> Sorry for the confusion, in fact there is nothing wrong with this code
> (ie it should be applied), the error was in the driver for the Dreamcast
> controller (the device, in general, into which the subdevices are
> plugged in and out).
> 
> I will post a fix for that.
> 
> Sorry again.
> 
So what exactly is supposed to be applied 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: 2.6.24 patches for mips qemu target needed for stable.

[Rob Landley]

On Sunday 24 February 2008 20:08:17 Ralf Baechle wrote:
> On Mon, Feb 25, 2008 at 10:36:59AM +0900, Samuel Masham wrote:
> > Hi Stable team,
> >
> > The mips build for qemu (and possibly other targets) crashes when
> > doing any irq probe.
> >
> > Specifically this happens on boot when brining up the ne driver.
> >
> > This is fixed by the following two patches from linus's tree
> >
> > 46f4f8f665080900e865392f4b3593be463bf0d8 - IRQ_NOPROBE helper functions
> > 24649c00ca334955ac7d8a79f5a7834fc7ea441d - MIPS: Mark all but i8259
> > interrupts as no-probe.
> >
> > They have no impact on any other architecture so I hope are simple to
> > include in the stable tree.
>
> ACK.

I'm using it against 2.6.24.2 here.  It applies cleanly and Works For Me (tm).

>   Ralf

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH] Update coding standard to avoid ungrepable printk format strings

[Andy Whitcroft]

On Fri, Feb 22, 2008 at 02:26:12PM +0100, Andi Kleen wrote:

> At some point checkpatch.pl would need to be updated to know about this
> exception too, that would be the next step.

Cirtainly we have exceptions for docstrings, so that shouldn't be a
problem if this were accepted.

-apw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86_64: for apic_is_clustered_box for vsmp v2

[Yinghai Lu]

quad core 8 socket system will have apic id lifting.the apic id range could
be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
and that is large than 2. So it is treated as clustered_box.

and will get

Marking TSC unstable due to TSCs unsynchronized

even the CPUs have X86_FEATURE_CONSTANT_TSC set.

quick fixwill check if the cpu is from AMD.

but vsmp still need that checking...

this patch is fix to make sure that vsmp not to be passed.

and need to be applied after
x86_64: make amd quad core 8 socket system not be clustered_box v2
in x86/testing

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

Index: linux-2.6/arch/x86/kernel/apic_64.c
===
--- linux-2.6.orig/arch/x86/kernel/apic_64.c
+++ linux-2.6/arch/x86/kernel/apic_64.c
@@ -1206,9 +1206,9 @@ __cpuinit int apic_is_clustered_box(void
 * there is not this kind of box with AMD CPU yet.
 * Some AMD box with quadcore cpu and 8 sockets apicid
 * will be [4, 0x23] or [8, 0x27] could be thought to
-* have three apic_clusters. So go out early.
+* vsmp box still need checking...
 */
-   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+   if (!is_vsmp_box() && (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
return 0;
 
bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
Index: linux-2.6/arch/x86/kernel/vsmp_64.c
===
--- linux-2.6.orig/arch/x86/kernel/vsmp_64.c
+++ linux-2.6/arch/x86/kernel/vsmp_64.c
@@ -72,19 +72,34 @@ static unsigned __init vsmp_patch(u8 typ
 
 }
 
+static int vsmp = -1;
+
+int is_vsmp_box(void)
+{
+   if (vsmp != -1)
+   return vsmp;
+
+   vsmp = 0;
+   if (!early_pci_allowed())
+   return vsmp;
+
+   /* Check if we are running on a ScaleMP vSMP box */
+   if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
+(PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL << 16)))
+   vsmp = 1;
+
+   return vsmp;
+}
+
 void __init vsmp_init(void)
 {
void *address;
unsigned int cap, ctl, cfg;
 
-   if (!early_pci_allowed())
+   if (!is_vsmp_box())
return;
 
-   /* Check if we are running on a ScaleMP vSMP box */
-   if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
-PCI_VENDOR_ID_SCALEMP) ||
-   (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
-PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
+   if (!early_pci_allowed())
return;
 
/* If we are, use the distinguished irq functions */
Index: linux-2.6/include/asm-x86/apic.h
===
--- linux-2.6.orig/include/asm-x86/apic.h
+++ linux-2.6/include/asm-x86/apic.h
@@ -51,12 +51,17 @@ extern unsigned boot_cpu_id;
  */
 #ifdef CONFIG_PARAVIRT
 #include 
+extern int is_vsmp_box(void);
 #else
 #define apic_write native_apic_write
 #define apic_write_atomic native_apic_write_atomic
 #define apic_read native_apic_read
 #define setup_boot_clock setup_boot_APIC_clock
 #define setup_secondary_clock setup_secondary_APIC_clock
+static int inline is_vsmp_box(void)
+{
+   return 0;
+}
 #endif
 
 static inline void native_apic_write(unsigned long reg, u32 v)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH] Update coding standard to avoid ungrepable printk format strings

[Andy Whitcroft]

On Sat, Feb 23, 2008 at 01:55:32PM +0100, Christer Weinigel wrote:
> Andi Kleen wrote:
> >RFC: Update coding standard to avoid split up printk format strings
> 
> While we're talking about checkpatch.pl, I'd definitely like to teach 
> checkpatch about "list_for_each" and friends.
> 
> list_for_each is flow control, not a function call.  I find it much 
> easier to see that something is a loop when there is a space between the 
> name and the parenthesis rather than when they are smashed together.
> 
> old patch follows
> 
>   /Christer
> 
> checkpatch complains about the following:
> 
> WARNING: no space between function name and open parenthesis '('
> #520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
> +   list_for_each_entry (transfer, >transfers, transfer_list) {
> 
> which I think is a bit bogus since it actually is a for statement in
> disguise.  The following patch adds list_for_each to the list of things
> that look like functions that it shouldn't complain about.
> 
> Index: linux-2.6.23/scripts/checkpatch.pl
> ===
> --- linux-2.6.23.orig/scripts/checkpatch.pl
> +++ linux-2.6.23/scripts/checkpatch.pl
> @@ -681,7 +681,7 @@ sub process {
> 
>  # check for spaces between functions and their parentheses.
>   if ($line =~ /($Ident)\s+\(/ &&
> - $1 !~ 
> /^(?:if|for|while|switch|return|volatile|__volatile__|__attribute__|format|__extension__|Copyright)$/
>  
> &&
> + $1 !~ 
> /^(?:if|for|while|switch|list_for_each.*|return|volatile|__volatile__|__attribute__|format|__extension__|Copyright)$/
>  
> &&
>   $line !~ /$Type\s+\(/ && $line !~ /^.\#\s*define\b/) {
>   WARN("no space between function name and open 
>   parenthesis '('\n" . $herecurr);
>   }

This has come up a few times.  In previous discussions there were
supporters for spaces as well as not.  Looking over the existing in kernel
use, the majority are without a space (from before checkpatch encouraged
that usage); and so it is that that won the day.

-apw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 [RT] 11/14] optimize the !printk fastpath through the lock acquisition

[Gregory Haskins]

Bill Huey (hui) wrote:


The might_sleep is annotation and well as a conditional preemption
point for the regular kernel. You might want to do a schedule check
there, but it's the wrong function if memory serves me correctly. It's
reserved for things that actually are design to sleep.


Note that might_sleep() already does a cond_resched() on the 
configurations that need it, so I am not sure what you are getting at 
here.  Is that not enough?




The rt_spin*()
function are really a method of preserving BKL semantics across real
schedule() calls. You'd have to use something else instead for that
purpose like cond_reschedule() instead.


I dont quite understand this part either.  From my perspective, 
rt_spin*() functions are locking constructs that might sleep (or might 
spin with the new patches), and they happen to be BKL and wakeup 
transparent.  To me, either the might_sleep() is correct for all paths 
that don't fit the in_atomic-printk exception, or none of them are.


Are you saying that the modified logic that I introduced is broken?  Or 
that the original use of the might_sleep() annotation inside this 
function is broken?


-Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] video: add a clamp() macro to kernel.h and replace two existing defs

[Mauro Carvalho Chehab]

On Sun, 24 Feb 2008 20:43:23 -0800
Harvey Harrison <[EMAIL PROTECTED]> wrote:

> Clamps a value to be within a given range with strict typechecking.
> 
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>

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

[PATCH] radeon: fix integer as NULL pointer warnings in radeon_mem.c

[Harvey Harrison]

drivers/char/drm/radeon_mem.c:91:23: warning: Using plain integer as NULL 
pointer
drivers/char/drm/radeon_mem.c:116:28: warning: Using plain integer as NULL 
pointer
drivers/char/drm/radeon_mem.c:124:28: warning: Using plain integer as NULL 
pointer
drivers/char/drm/radeon_mem.c:177:26: warning: Using plain integer as NULL 
pointer
drivers/char/drm/radeon_mem.c:177:53: warning: Using plain integer as NULL 
pointer

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 drivers/char/drm/radeon_mem.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/drm/radeon_mem.c b/drivers/char/drm/radeon_mem.c
index 78b34fa..4af5286 100644
--- a/drivers/char/drm/radeon_mem.c
+++ b/drivers/char/drm/radeon_mem.c
@@ -88,7 +88,7 @@ static struct mem_block *alloc_block(struct mem_block *heap, 
int size,
 
list_for_each(p, heap) {
int start = (p->start + mask) & ~mask;
-   if (p->file_priv == 0 && start + size <= p->start + p->size)
+   if (p->file_priv == NULL && start + size <= p->start + p->size)
return split_block(p, start, size, file_priv);
}
 
@@ -113,7 +113,7 @@ static void free_block(struct mem_block *p)
/* Assumes a single contiguous range.  Needs a special file_priv in
 * 'heap' to stop it being subsumed.
 */
-   if (p->next->file_priv == 0) {
+   if (p->next->file_priv == NULL) {
struct mem_block *q = p->next;
p->size += q->size;
p->next = q->next;
@@ -121,7 +121,7 @@ static void free_block(struct mem_block *p)
drm_free(q, sizeof(*q), DRM_MEM_BUFS);
}
 
-   if (p->prev->file_priv == 0) {
+   if (p->prev->file_priv == NULL) {
struct mem_block *q = p->prev;
q->size += p->size;
q->next = p->next;
@@ -174,7 +174,7 @@ void radeon_mem_release(struct drm_file *file_priv, struct 
mem_block *heap)
 * 'heap' to stop it being subsumed.
 */
list_for_each(p, heap) {
-   while (p->file_priv == 0 && p->next->file_priv == 0) {
+   while (p->file_priv == NULL && p->next->file_priv == NULL) {
struct mem_block *q = p->next;
p->size += q->size;
p->next = q->next;
-- 
1.5.4.2.200.g99e75



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Aborted commands with arcmsr and 2xWD1500ADFD in RAID1

[nickcheng]

Hi Aron,
>From our field experiences and customers' feedbacks, all of them direct to
vibration and power issues.
The vibration could be caused by FANs not only by themselves.
You mentioned it could be the F/W issue.
If the environment does not meet the prerequisite, FW could not work
correctly.
Actually FW just reacts to the situations not it causes the issue.
Please check it out!!
Thank you,

-Original Message-
From: Aron Stansvik [mailto:[EMAIL PROTECTED] 
Sent: Sunday, February 24, 2008 1:54 AM
To: [EMAIL PROTECTED]
Cc: erich; [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org
Subject: Re: Aborted commands with arcmsr and 2xWD1500ADFD in RAID1

Hello again Areca and LKML hackers.

2008/2/18, Aron Stansvik <[EMAIL PROTECTED]>:
> Hello Nick.
>
>  Sorry that I'm not answering until now. I've been busy.
>
>  2008/2/13, nickcheng <[EMAIL PROTECTED]>:
>
> > Hi Aron,
>  >  From our experience and some customers' feedback, your issue could be
caused
>  >  by power instability or vibration to your HDs.
>  >  Please check step by step:
>  >  (1).under your original environment, increase the SCSI command value,
>  >  default=30, with the shell script, set_scsicmd_timeout(). 90 or 120 is
>  >  enough.
>  >  (2).if method 1 does not work, find out the vibration source or change
the
>  >  power supply
>
>
> I will try to increase that value. I don't think it's vibration; the
>  disks are firmly in place in a very heavy chassi (Silverstone
>  SST-TJ05B-T). And I really don't think there's something wrong with
>  the power supply, it's a pretty new Silverstone ST65ZF 650W. This is
>  my own personal workstation, so I don't just have another power supply
>  to test with :/
>
>  I will report back on my success/failure. Thanks for your answer.

I've now tried with both 90 and 120 for the timeout value, and the
problem still persists. It seems to happen when lots of small writes
are occuring, e.g. when installing something.

I really don't think the disks are vibrating, I don't see how they
could. One more thing I'm going to test is to use the legacy ATA power
connector instead of the SATA power connector. This was what I was
using before when I only had a single drive and no RAID controller.
Maybe my power supply is malfunctioning and not giving enough power on
the SATA power connectors.. but I doubt it.

Is there anything else that could cause this? Have you guys at Areca
tested the ARC-1200 with Raptors in RAID1?

:(

Regards,
Aron

>
>
>  Aron
>
>
>  >  If your still have any questions, please feel free to let me know.
>  >
>  >  P.S. The attached driver source, arcmsr-1.20.00.15-71224, has been
>  >  upstreamed to kernel.org and will be released in kernel 2.6.25. If you
like,
>  >  you could update your driver with it.
>  >  It fixes some minor bugs, but these bugs are nothing to do with your
issue.
>  >
>  >
>  >  -Original Message-
>  >  From: erich [mailto:[EMAIL PROTECTED]
>  >  Sent: Wednesday, February 13, 2008 4:33 PM
>  >  To: (廣安科技)鄭守謙
>  >  Subject: Fw: Aborted commands with arcmsr and 2xWD1500ADFD in RAID1
>  >
>  >
>  >
>  >  - Original Message -
>  >  From: "Andrew Morton" <[EMAIL PROTECTED]>
>  >  To: "Aron Stansvik" <[EMAIL PROTECTED]>
>  >  Cc: ; <[EMAIL PROTECTED]>;
"erich"
>  >  <[EMAIL PROTECTED]>
>  >  Sent: Wednesday, February 13, 2008 4:03 PM
>  >  Subject: Re: Aborted commands with arcmsr and 2xWD1500ADFD in RAID1
>  >
>  >
>  >  >
>  >  > (cc's added)
>  >  >
>  >  > On Mon, 11 Feb 2008 17:44:08 +0100 "Aron Stansvik"
<[EMAIL PROTECTED]>
>  >  > wrote:
>  >  >
>  >  >> Hello LKML.
>  >  >>
>  >  >> Under semi-high disk I/O (e.g. installing a compiled KDE), I get
the
>  >  >> following (accompanied by seconds of lock-ups on the machine):
>  >  >>
>  >  >> [ 7727.345183] arcmsr0: abort device command of scsi id = 0 lun = 0
>  >  >> [ 7730.348776] arcmsr0: scsi id = 0 lun = 0 ccb =
>  >  >> '0xdfb461c0' poll command abort successfully
>  >  >> [ 8053.795943] arcmsr0: abort device command of scsi id = 0 lun = 0
>  >  >> [ 8056.799528] arcmsr0: scsi id = 0 lun = 0 ccb =
>  >  >> '0xdfb595e0' poll command abort successfully
>  >  >> [ 8884.592810] arcmsr0: abort device command of scsi id = 0 lun = 0
>  >  >> [ 8887.596392] arcmsr0: scsi id = 0 lun = 0 ccb =
>  >  >> '0xdfb56d80' poll command abort successfully
>  >  >> [ 8917.760216] arcmsr0: abort device command of scsi id = 0 lun = 0
>  >  >> [ 8920.763797] arcmsr0: scsi id = 0 lun = 0 ccb =
>  >  >> '0xdfb472c0' poll command abort successfully
>  >  >> [ 9074.106547] arcmsr0: abort device command of scsi id = 0 lun = 0
>  >  >>
>  >  >> This is my setup:
>  >  >>
>  >  >> 1 x MSI K8N Master2-FAR
>  >  >> 1 x Opteron 252
>  >  >> 1 x Areca ARC1200 (sitting in a PCIe x4 socket)
>  >  >> 2 x WD1500ADFD in RAID1
>  >  >>
>  >  >> [EMAIL PROTECTED]:~$ uname -a
>  >  >> Linux rubik 2.6.24-7-generic #1 SMP Thu Feb 7 01:29:58 UTC 2008
i686
>  >  >> 

[PATCH] video: add a clamp() macro to kernel.h and replace two existing defs

[Harvey Harrison]

Clamps a value to be within a given range with strict typechecking.

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
akpm: I've submitted a clamp_t version previously for use in libata.
You may want to just roll this into that one so clamp/clamp_t go in
together.

 drivers/media/video/bt8xx/bttvp.h|2 --
 drivers/media/video/usbvideo/vicam.c |6 --
 include/linux/kernel.h   |   13 +
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/media/video/bt8xx/bttvp.h 
b/drivers/media/video/bt8xx/bttvp.h
index 1305d31..b38e3a0 100644
--- a/drivers/media/video/bt8xx/bttvp.h
+++ b/drivers/media/video/bt8xx/bttvp.h
@@ -82,8 +82,6 @@
 /* Limits scaled width, which must be a multiple of 4. */
 #define MAX_HACTIVE (0x3FF & -4)
 
-#define clamp(x, low, high) min (max (low, x), high)
-
 #define BTTV_NORMS(\
V4L2_STD_PAL| V4L2_STD_PAL_N | \
V4L2_STD_PAL_Nc | V4L2_STD_SECAM | \
diff --git a/drivers/media/video/usbvideo/vicam.c 
b/drivers/media/video/usbvideo/vicam.c
index da1ba02..938a60d 100644
--- a/drivers/media/video/usbvideo/vicam.c
+++ b/drivers/media/video/usbvideo/vicam.c
@@ -70,12 +70,6 @@
 
 #define VICAM_HEADER_SIZE   64
 
-#define clamp( x, l, h )max_t( __typeof__( x ), \
-  ( l ),   \
-  min_t( __typeof__( x ),  \
- ( h ),\
- ( x ) ) )
-
 /* Not sure what all the bytes in these char
  * arrays do, but they're necessary to make
  * the camera work.
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 47924ce..09ee1e0 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -352,6 +352,19 @@ static inline int __attribute__ ((format (printf, 1, 2))) 
pr_debug(const char *
_x > _y ? _x : _y; })
 
 /*
+ * Clamp a value to within a given range with strict type checking
+ */
+#define clamp(val,min,max) ({ \
+   typeof(val) __val = (val); \
+   typeof(min) __min = (min); \
+   typeof(max) __max = (max); \
+   (void) (&__val == &__min); \
+   (void) (&__val == &__max); \
+   __val = __val < __min ? __min: __val; \
+   __val > __max ? __max: __val; })
+
+
+/*
  * ..and if you can't take the strict
  * types, you can specify one yourself.
  *
-- 
1.5.4.2.200.g99e75



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.25-rc3] lockdep: add spin_lock_irq_nested()

[David Brownell]

> > > ==> LOCKDEP feature is evidently missing:
> > > spin_lock_irq_nested(lock_ptr, lock_class)
> > 
> > This rant is more lines than adding the API :-/ the reason for it not
> > being there is simple, it wasn't needed up until now.
> 
> I suspected that was the case, but for all I knew there was some
> religious objection. 

Does this look about right?  Or, I suppose it could just call
the _spin_lock_irqsave_nested() routine and discard the result.

- Dave

=CUT HERE
Add new spin_lock_irq_nested() call, so that lockdep can work with the
code which uses spin_*_irq() calls that don't save/restore flags.

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Against 2.6.25-rc3

 include/linux/spinlock.h |6 ++
 include/linux/spinlock_api_smp.h |2 ++
 kernel/spinlock.c|   21 +++--
 3 files changed, 27 insertions(+), 2 deletions(-)

--- a/include/linux/spinlock.h  2008-02-24 18:50:50.0 -0800
+++ b/include/linux/spinlock.h  2008-02-24 19:02:39.0 -0800
@@ -196,9 +196,13 @@ do {   
\
 #define write_lock_irqsave(lock, flags)flags = 
_write_lock_irqsave(lock)
 
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
+#define spin_lock_irq_nested(lock, subclass) \
+   _spin_lock_irq_nested(lock, subclass)
 #define spin_lock_irqsave_nested(lock, flags, subclass) \
flags = _spin_lock_irqsave_nested(lock, subclass)
 #else
+#define spin_lock_irq_nested(lock, subclass) \
+   _spin_lock_irq(lock)
 #define spin_lock_irqsave_nested(lock, flags, subclass) \
flags = _spin_lock_irqsave(lock)
 #endif
@@ -208,6 +212,8 @@ do {
\
 #define spin_lock_irqsave(lock, flags) _spin_lock_irqsave(lock, flags)
 #define read_lock_irqsave(lock, flags) _read_lock_irqsave(lock, flags)
 #define write_lock_irqsave(lock, flags)_write_lock_irqsave(lock, flags)
+#define spin_lock_irq_nested(lock, subclass) \
+   spin_lock_irq(lock)
 #define spin_lock_irqsave_nested(lock, flags, subclass)\
spin_lock_irqsave(lock, flags)
 
--- a/include/linux/spinlock_api_smp.h  2008-02-24 18:50:50.0 -0800
+++ b/include/linux/spinlock_api_smp.h  2008-02-24 19:02:39.0 -0800
@@ -28,6 +28,8 @@ void __lockfunc _spin_lock_bh(spinlock_t
 void __lockfunc _read_lock_bh(rwlock_t *lock)  __acquires(lock);
 void __lockfunc _write_lock_bh(rwlock_t *lock) __acquires(lock);
 void __lockfunc _spin_lock_irq(spinlock_t *lock)   __acquires(lock);
+void __lockfunc _spin_lock_irq_nested(spinlock_t *lock, int subclass)
+   __acquires(lock);
 void __lockfunc _read_lock_irq(rwlock_t *lock) __acquires(lock);
 void __lockfunc _write_lock_irq(rwlock_t *lock)
__acquires(lock);
 unsigned long __lockfunc _spin_lock_irqsave(spinlock_t *lock)
--- a/kernel/spinlock.c 2008-02-24 18:50:50.0 -0800
+++ b/kernel/spinlock.c 2008-02-24 19:02:39.0 -0800
@@ -290,8 +290,26 @@ void __lockfunc _spin_lock_nested(spinlo
spin_acquire(>dep_map, subclass, 0, _RET_IP_);
LOCK_CONTENDED(lock, _raw_spin_trylock, _raw_spin_lock);
 }
-
 EXPORT_SYMBOL(_spin_lock_nested);
+
+void __lockfunc _spin_lock_irq_nested(spinlock_t *lock, int subclass)
+{
+   local_irq_disable();
+   preempt_disable();
+   spin_acquire(>dep_map, subclass, 0, _RET_IP_);
+   /*
+* On lockdep we dont want the hand-coded irq-enable of
+* _raw_spin_lock_flags() code, because lockdep assumes
+* that interrupts are not re-enabled during lock-acquire:
+*/
+#ifdef CONFIG_LOCKDEP
+   LOCK_CONTENDED(lock, _raw_spin_trylock, _raw_spin_lock);
+#else
+   _raw_spin_lock_flags(lock, );
+#endif
+}
+EXPORT_SYMBOL(_spin_lock_irq_nested);
+
 unsigned long __lockfunc _spin_lock_irqsave_nested(spinlock_t *lock, int 
subclass)
 {
unsigned long flags;
@@ -311,7 +329,6 @@ unsigned long __lockfunc _spin_lock_irqs
 #endif
return flags;
 }
-
 EXPORT_SYMBOL(_spin_lock_irqsave_nested);
 
 #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Clocksource tsc is always unstable with 2.6.25-* kernels and CONFIG_NO_HZ=y on my box

[Robert Hancock]

Gabriel C wrote:

Hi,

I noticed tsc is always marked unstable on my box with 2.6.25* , 2.6.24 is fine.

..

[0.825760] ACPI: PCI Interrupt :03:0e.0[A] -> GSI 22 (level, low) -> 
IRQ 22
[0.805755] Switched to high resolution mode on CPU 1
[0.794244] Switched to high resolution mode on CPU 2
[0.766968] Switched to high resolution mode on CPU 3
[1.083944] Switched to high resolution mode on CPU 0
[   15.388792] Clocksource tsc unstable (delta = 9373391604 ns)
[   15.714648] Time: acpi_pm clocksource has been installed.

..

Booting nohz=off fixes that.

Another strange thing is when I try to boot that kernel with 
clocksource=acpi_pm it just hangs.

config is attached.

Please let me know if you need more infos / want me to try patches or anything 
else.


Please post your full dmesg output.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] exporting capability name/code pairs (final)

[Kohei KaiGai]

Li Zefan wrote:
>> [2/3] Exporting capability code/name pairs
>>
>> This patch enables to export code/name pairs of capabilities the running
>> kernel supported.
>>
> 
> supported or supports ?

It seems to me "supports" is more appropriate one.

The original one might mention legacy versions. :-(

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

Re: [git patches] net driver fixes (50% rebased)

[David Miller]

From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun, 24 Feb 2008 00:20:41 -0500

> 
> This is a 50% resend, rebased on top of net-2.6.
> 
> Please pull from 'upstream-davem' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
> upstream-davem
> 
> to receive the following updates:

Pulled and pushed back out, thanks 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: [Regression in 2.6.25-rcX] CD/DVD writer no longer works

[Mike Galbraith]

On Sun, 2008-02-24 at 12:57 -0800, zkopex wrote:
> Hello,

Greetings,

> I am using Debian Sid on a Toshiba A100 laptop. My CD/DVD
> writer functions very well on 2.6.23.16 and 2.6.24.2.
> 
> I tried 2.6.25-rc2-git7, and I was very sad to notice that
> when I tried to write a CD, wodim started to output the
> following: "Warning: controller returns zero sized CD
> capabilities page."

Yeah, I saw that using k3b.

> Since I was able to use this CD/DVD writer successfully with
> previous versions of Linux, I believe that this is a regression
> in 2.6.25-rcX series.
> 
> I am willing to try patches and to do pretty much anything
> to debug/fix this problem.

Sounds like you're having the same problem I am.  In my case, reverting
all but one line of commit 6b00769fe1502b4ad97bb327ef7ac971b208bfb5
cures it, though I don't see why.

Revert patch below is against freshly hatched rc3 if you want to try it.

diff --git a/block/blk-core.c b/block/blk-core.c
index 775c851..c013ca2 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -127,7 +127,6 @@ void rq_init(struct request_queue *q, struct request *rq)
rq->nr_hw_segments = 0;
rq->ioprio = 0;
rq->special = NULL;
-   rq->raw_data_len = 0;
rq->buffer = NULL;
rq->tag = -1;
rq->errors = 0;
@@ -2016,7 +2015,6 @@ void blk_rq_bio_prep(struct request_queue *q, struct 
request *rq,
rq->hard_cur_sectors = rq->current_nr_sectors;
rq->hard_nr_sectors = rq->nr_sectors = bio_sectors(bio);
rq->buffer = bio_data(bio);
-   rq->raw_data_len = bio->bi_size;
rq->data_len = bio->bi_size;
 
rq->bio = rq->biotail = bio;
diff --git a/block/blk-map.c b/block/blk-map.c
index 09f7fd0..ae4a0fc 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -19,7 +19,6 @@ int blk_rq_append_bio(struct request_queue *q, struct request 
*rq,
rq->biotail->bi_next = bio;
rq->biotail = bio;
 
-   rq->raw_data_len += bio->bi_size;
rq->data_len += bio->bi_size;
}
return 0;
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 7506c4f..a15d0ee 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -231,7 +231,6 @@ new_segment:
((unsigned long)q->dma_drain_buffer) &
(PAGE_SIZE - 1));
nsegs++;
-   rq->data_len += q->dma_drain_size;
}
 
if (sg)
diff --git a/block/bsg.c b/block/bsg.c
index 7f3c095..8917c51 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -437,14 +437,14 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq, 
struct sg_io_v4 *hdr,
}
 
if (rq->next_rq) {
-   hdr->dout_resid = rq->raw_data_len;
-   hdr->din_resid = rq->next_rq->raw_data_len;
+   hdr->dout_resid = rq->data_len;
+   hdr->din_resid = rq->next_rq->data_len;
blk_rq_unmap_user(bidi_bio);
blk_put_request(rq->next_rq);
} else if (rq_data_dir(rq) == READ)
-   hdr->din_resid = rq->raw_data_len;
+   hdr->din_resid = rq->data_len;
else
-   hdr->dout_resid = rq->raw_data_len;
+   hdr->dout_resid = rq->data_len;
 
/*
 * If the request generated a negative error number, return it
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index e993cac..9675b34 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -266,7 +266,7 @@ static int blk_complete_sghdr_rq(struct request *rq, struct 
sg_io_hdr *hdr,
hdr->info = 0;
if (hdr->masked_status || hdr->host_status || hdr->driver_status)
hdr->info |= SG_INFO_CHECK;
-   hdr->resid = rq->raw_data_len;
+   hdr->resid = rq->data_len;
hdr->sb_len_wr = 0;
 
if (rq->sense_len && hdr->sbp) {
@@ -528,7 +528,6 @@ static int __blk_send_generic(struct request_queue *q, 
struct gendisk *bd_disk,
rq = blk_get_request(q, WRITE, __GFP_WAIT);
rq->cmd_type = REQ_TYPE_BLOCK_PC;
rq->data = NULL;
-   rq->raw_data_len = 0;
rq->data_len = 0;
rq->timeout = BLK_DEFAULT_SG_TIMEOUT;
memset(rq->cmd, 0, sizeof(rq->cmd));
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 0562b0a..85d 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2539,7 +2539,7 @@ static unsigned int atapi_xlat(struct ata_queued_cmd *qc)
 * want to set it properly, and for DMA where it is
 * effectively meaningless.
 */
-   nbytes = min(scmd->request->raw_data_len, (unsigned int)63 * 1024);
+   nbytes = min(qc->nbytes, (unsigned int)63 * 1024);
 
/* Most ATAPI devices which honor transfer chunk size don't
 * behave according to the spec when odd chunk size which
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 6fe67d1..094eba2 100644
--- a/include/linux/blkdev.h
+++ 

Re: [PATCH] Change a WARN message in checkpatch

[Andy Whitcroft]

On Sun, Feb 24, 2008 at 07:14:13PM +0100, Paolo Ciarrocchi wrote:
> On Sun, Feb 24, 2008 at 4:18 PM, Benny Halevy <[EMAIL PROTECTED]> wrote:
> [...]
> >  How about:
> >  -   WARN("no space between function name and 
> > open parenthesis '('\n" . $herecurr);
> >  +   WARN("there should be no space between 
> > function name and open parenthesis '('\n" . $herecurr);
> 
> I originally suggested:
> +   WARN("don't put a space between
> function name and open parenthesis '('\n" . $herecurr);
> but I really prefer your version.
> 
> >  The original phrasing can be interpreted like "there is no space between 
> > ..." and the correct
> >  interpretation should be "there should be no space between ..."
> 
> Indeed.

As we want the messages to be as short as possible, I am leaning towards
standardising on:

spaces prohibited 
spaces required 

-apw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Tiny cpusets -- cpusets for small systems?

[KOSAKI Motohiro]

Hi Pual

> Looking at some IA64 sn2 config builds I have laying about, I see the
> following text sizes for a couple of versions, showing the growth of
> the cpuset/cgroup apparatus over time:
> 
>   25933   2.6.18-rc3-mm1/kernel/cpuset.o (Aug 2006)
> vs.
>   37823   2.6.25-rc2-mm1/kernel/cgroup.o (Feb 2008)
>   19558   2.6.25-rc2-mm1/kernel/cpuset.o
> 
> So the total has grown from 25933 to 57381 text bytes (note that
> this is IA64 arch; most arch's will have proportionately smaller
> text sizes.)

hm, interesting.
but unfortunately the cpuset have more than depend.(i.e. CONFIG_SMP)

To more bad thing, some embedded cpu have poor or no atomic instruction
support.
at that, turn on CONFIG_SMP become large performace regression ;)


I am not already embedded engineer.
thus, I might have made a mistake.
(BTW: I am large server engineer now)

but no thinking dependency is wrong, may be.


Pavel, what do you think it?

- kosaki


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.25-rc1/2 CD/DVD burning broken

[Kiyoshi Ueda]

Hi Andreas,

On Sat, 23 Feb 2008 16:47:50 +0100, Andreas Schwab wrote:

Kiyoshi Ueda <[EMAIL PROTECTED]> writes:

> Could you try this patch?
> I've only done a compile test, so this patch may not work.

Unfortunately, that is not enough to get DVD burning working again.
This is the error that growisofs is getting:

ioctl(6, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 00, 00, 03, 10, 
00, 00, 10, 00], mx_sb_len=64, iovec_count=0, dxfer_len=32768, 
timeout=6, flags=0x3, 
data[32768]=["\360R\360\314Wt\277\241\36.\347\356L$\201]\210\372_~]I\213\366\253SV\2\372\356\312\257"...], 
status=02, masked_status=01, sb[0]=[], host_status=0, driver_status=0, 
resid=32768, duration=0, info=0x1}) = 0

write(2, ":-( unable to [EMAIL PROTECTED]: ", 30) = 30

It looks like the sense buffer is not filled in.  In a successfully run
of growisfs under 2.6.24.2 the sense code is "LONG WRITE IN PROGRESS".

I also see that resid always equals dxfer_len even when the transfer was
successful, although growisofs does not seem to care.  With 2.6.24.2
resid is only non-zero when a sense error occurred.


I'm looking at this problem, but currently no idea why the conversion
to blk_end_request causes it.

growisofs (in dvd+rw-tools-7.0) seems to care only the sense buffer
of the sg_io_hdr, as you said.
(growisofs_mmc.cpp:poor_mans_pwrite64() and transport.hxx:transport())
So if the driver sets the sense code correctly, growisofs should work
correctly I think.
However, I can't find why the blk_end_request patch affects the sense
code setting.

Could you give me some more information below to help investigation?
 o Have you tried bisecting the kernel changes to find suspicious
   commit?  If so, that information will be much appreciated.
 o Is this problem 100% reproducible on your Pioneer drive?
 o What is your dvd+rw-tools version?
 o Do you get some messages from kernel like "DMA error" when
   the problem happens?

And I'm sorry but I can't make enough time for this problem
until late this week.

Thanks,
Kiyoshi Ueda

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Tabs, spaces, indent and 80 character lines

[Miles Bader]

Why do people even respond to these trolls...?

-Miles

-- 
Success, n. The one unpardonable sin against one's fellows.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86_64: make amd quad core 8 socket system not be clustered_box v2

[Yinghai Lu]

please check the fix for v2.

this one can be applied to x86.git#testing

YH

---
[PATCH] x86_64: apic_is_clustered_box fix for vsmp

quad core 8 socket system will have apic id lifting.the apic id range could
be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
and that is large than 2. So it is treated as clustered_box.

and will get

Marking TSC unstable due to TSCs unsynchronized

even the CPUs have X86_FEATURE_CONSTANT_TSC set.

v2 patch will check if the cpu is from AMD.

vsmp still need that checking...

this patch is fix for vsmp

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index 8f6c45e..8a47579 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1206,9 +1206,9 @@ __cpuinit int apic_is_clustered_box(void)
 * there is not this kind of box with AMD CPU yet.
 * Some AMD box with quadcore cpu and 8 sockets apicid
 * will be [4, 0x23] or [8, 0x27] could be thought to
-* have three apic_clusters. So go out early.
+* vsmp box still need checking...
 */
-   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+   if (!is_vsmp_box() && (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
return 0;
 
bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index 54202b1..09e16ff 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -72,19 +72,34 @@ static unsigned __init vsmp_patch(u8 type, u16 clobbers, 
void *ibuf,
 
 }
 
+static int vsmp = -1;
+
+int is_vsmp_box(void)
+{
+   if (vsmp != -1)
+   return vsmp;
+
+   vsmp = 0;
+   if (!early_pci_allowed())
+   return vsmp;
+
+   /* Check if we are running on a ScaleMP vSMP box */
+   if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
+(PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL << 16)))
+   vsmp = 1;
+
+   return vsmp;
+}
+
 void __init vsmp_init(void)
 {
void *address;
unsigned int cap, ctl, cfg;
 
-   if (!early_pci_allowed())
+   if (!vsmp)
return;
 
-   /* Check if we are running on a ScaleMP vSMP box */
-   if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
-PCI_VENDOR_ID_SCALEMP) ||
-   (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
-PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
+   if (!early_pci_allowed())
return;
 
/* If we are, use the distinguished irq functions */
diff --git a/include/asm-x86/apic.h b/include/asm-x86/apic.h
index a68dc6b..24f7a05 100644
--- a/include/asm-x86/apic.h
+++ b/include/asm-x86/apic.h
@@ -51,12 +51,17 @@ extern unsigned boot_cpu_id;
  */
 #ifdef CONFIG_PARAVIRT
 #include 
+extern int is_vsmp_box(void);
 #else
 #define apic_write native_apic_write
 #define apic_write_atomic native_apic_write_atomic
 #define apic_read native_apic_read
 #define setup_boot_clock setup_boot_APIC_clock
 #define setup_secondary_clock setup_secondary_APIC_clock
+int inline is_vsmp_box(void)
+{
+   return 0;
+}
 #endif
 
 static inline void native_apic_write(unsigned long reg, u32 v)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10030] Suspend doesn't work when SD card is inserted

[Alan Stern]

On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:

> > Very subtly wrong ;-).
> > 
> > imagine suspending_task == 0xabcdef01. Now task "R" with current ==
> > 0xabcd reads suspending_task while the other cpu is writing to it,
> > and sees 0xabcd (0xef01 was not yet written) -- and mistakenly
> > believes that  "R" == suspending_task.
> > 
> > I agree it is very unlikely, and it will not happen on i386. But what
> > about just using atomic_t suspending_task, and store current->pid into
> > it?
> 
> I'd rather use a lock, frankly.  For example, we can require the readers to
> take pm_sleep_rwsem for reading in order to access that.

That certainly won't work.  Imagine what would happen when the reader 
_was_ the suspending task.

But if you really twist my arm, I'll go along with Pavel's suggestion.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Remove the macro get_personality

[WANG Cong]

From: WANG Cong <[EMAIL PROTECTED]>
Date: Sun, 24 Feb 2008 12:09:03 +0800
Subject: [PATCH] Remove the macro get_personality

Remove the macro get_personality, use ->personality instead.

Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]
Cc: Alexey Dobriyan <[EMAIL PROTECTED]>
Cc: David Howells <[EMAIL PROTECTED]>
Cc: Bryan Wu <[EMAIL PROTECTED]>
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
 arch/blackfin/kernel/signal.c |2 +-
 arch/frv/kernel/signal.c  |4 ++--
 include/linux/personality.h   |4 
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/blackfin/kernel/signal.c b/arch/blackfin/kernel/signal.c
index 5564c95..e8d3869 100644
--- a/arch/blackfin/kernel/signal.c
+++ b/arch/blackfin/kernel/signal.c
@@ -224,7 +224,7 @@ setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t * 
info,
 
/* Set up registers for signal handler */
wrusp((unsigned long)frame);
-   if (get_personality & FDPIC_FUNCPTRS) {
+   if (current->personality & FDPIC_FUNCPTRS) {
struct fdpic_func_descriptor __user *funcptr =
(struct fdpic_func_descriptor *) ka->sa.sa_handler;
__get_user(regs->pc, >text);
diff --git a/arch/frv/kernel/signal.c b/arch/frv/kernel/signal.c
index d64bcaf..3bdb368 100644
--- a/arch/frv/kernel/signal.c
+++ b/arch/frv/kernel/signal.c
@@ -297,7 +297,7 @@ static int setup_frame(int sig, struct k_sigaction *ka, 
sigset_t *set)
__frame->lr   = (unsigned long) >retcode;
__frame->gr8  = sig;
 
-   if (get_personality & FDPIC_FUNCPTRS) {
+   if (current->personality & FDPIC_FUNCPTRS) {
struct fdpic_func_descriptor __user *funcptr =
(struct fdpic_func_descriptor __user *) 
ka->sa.sa_handler;
__get_user(__frame->pc, >text);
@@ -396,7 +396,7 @@ static int setup_rt_frame(int sig, struct k_sigaction *ka, 
siginfo_t *info,
__frame->gr8 = sig;
__frame->gr9 = (unsigned long) >info;
 
-   if (get_personality & FDPIC_FUNCPTRS) {
+   if (current->personality & FDPIC_FUNCPTRS) {
struct fdpic_func_descriptor __user *funcptr =
(struct fdpic_func_descriptor __user *) 
ka->sa.sa_handler;
__get_user(__frame->pc, >text);
diff --git a/include/linux/personality.h b/include/linux/personality.h
index 012cd55..a84e9ff 100644
--- a/include/linux/personality.h
+++ b/include/linux/personality.h
@@ -105,10 +105,6 @@ struct exec_domain {
  */
 #define personality(pers)  (pers & PER_MASK)
 
-/*
- * Personality of the currently running process.
- */
-#define get_personality(current->personality)
 
 /*
  * Change personality of the currently running process.
-- 
1.5.3.8

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

Re: [PATCH] Fix alignment of early reservation for EBDA

[H. Peter Anvin]

Alexander van Heukelum wrote:

Hi Andi,

My eyes fell on the following table in the boot messages:

early res: 0 [0-fff] BIOS data page
early res: 1 [6000-7fff] SMP_TRAMPOLINE
early res: 2 [20-374557] TEXT DATA BSS
early res: 3 [9fc00-a0bff] EBDA
early res: 4 [8000-afff] PGTABLE

The memory reserved for the EBDA overflows into the area normally
reserved for the VGA adaptor. It seems that you wanted to force
the allocation to cover whole pages, like:

early res: 3 [9f000-9] EBDA

This is what this patch implements.

Is it really necessary to force the allocation to a page boundary?



It is, but that rounding gets done in reserve_bootmem() anyway, so there 
is no need for the arch-specific code to do it.


The 32-bit EBDA code hard-codes a size of 4K, which is probably equally 
wrong; my gut feel is that the right thing to do is to reserve from the 
EBDA up to the 640K mark (some BIOSes use an area like that for SMM 
stuff), possibly with some sanity checking.


-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10030] Suspend doesn't work when SD card is inserted

[Alan Stern]

On Sun, 24 Feb 2008, Pavel Machek wrote:

> > > At the very least, you'd need rmb() before reading it and wmb() after
> > > writing to it, but I'm not sure if that's enough on every obscure
> > > architecture out there.
> > 
> > No, neither one is needed because of the way suspending_task is used.  
> > 
> > It's not necessary for a reader R to see the variable's actual value;  
> > all R needs to know is whether or not suspending_task is equal to R.  
> > Since the only process which can set suspending_task to R is R itself,
> > and since R will set suspending_task back to NULL before releasing the
> > write lock on pm_sleep_rwsem, there's never any ambiguity.
> 
> Subtle.
> 
> Very subtly wrong ;-).
> 
> imagine suspending_task == 0xabcdef01. Now task "R" with current ==
> 0xabcd reads suspending_task while the other cpu is writing to it,
> and sees 0xabcd (0xef01 was not yet written) -- and mistakenly
> believes that  "R" == suspending_task.

I always thought that reads and writes of pointers are atomic, just 
like reads and writes of longs.  Is that wrong?

Now if pointers were the same size as long long then I would agree with 
you.

> I agree it is very unlikely, and it will not happen on i386. But what
> about just using atomic_t suspending_task, and store current->pid into
> it?

That would work just as well.  Except that it wouldn't need to be
atomic_t, because current->pid is always an integer (not guaranteed, I
suppose, but that's what it is on all current architectures) and
reads/writes of ints _are_ atomic.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Q] x86 - boot/header.S

[H. Peter Anvin]

Cyrill Gorcunov wrote:

Look, we only have head64.c - there is no head32.c at all.


That's true to some degree, but head64.c contains a bunch of stuff which 
lives in setup_32.c in the 32-bit world.


-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Q] x86 - boot/header.S

[H. Peter Anvin]

Cyrill Gorcunov wrote:

Hi Peter, Sam,

could you take a look on x86/boot/header.S:280 please?

# Zero the bss
movw$__bss_start, %di
movw$_end+3, %cx
xorl%eax, %eax
subw%di, %cx
shrw$2, %cx
rep; stosl

I wonder why is $_end there instead of $__bss_stop?
Well, accroding to vmlinux_32.lsd both _end and __bss_stop
are the same BUT __bss_stop is more convenient methink.
Would it be usefull to change?


x86/boot/header.S goes with x86/boot/setup.ld and no other linker script.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: boot_delay broken ?

[Dave Young]

On Sun, Feb 24, 2008 at 8:46 AM, Dave Jones <[EMAIL PROTECTED]> wrote:
> The boot_delay switch seems to be behaving strangely in the
>  current -git.  Setting it to =10 makes the output 'bursty'
>  it becomes slow for some printk's whilst others scroll by
>  at regular speed.
>  Setting it any higher than that seems to make it pause for
>  a really long time before it outputs any text at all.

On my side there's this issue for a long time
http://lkml.org/lkml/2007/8/8/79

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

2.6.25-rc3: WARNING: at arch/x86/mm/ioremap.c:137

[Phil Oester]

Got the below on -rc3.  Tried applying the "more info" patch from Arjan
(http://marc.info/?l=linux-kernel=120336371506283=2), but that just
made the warning go away.  

Phil



ACPI: EC: Look up EC in DSDT
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:137 __ioremap+0xb1/0x16b()
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.25-rc3 #7
 [] warn_on_slowpath+0x40/0x4f
 [] acpi_ut_update_object_reference+0xb0/0x109
 [] acpi_ns_lookup+0x205/0x2ea
 [] acpi_ut_release_mutex+0x50/0x55
 [] acpi_ns_get_node+0x79/0x83
 [] raw_pci_read+0x3d/0x45
 [] acpi_ut_acquire_mutex+0x2e/0x64
 [] acpi_ut_release_mutex+0x50/0x55
 [] acpi_get_parent+0x63/0x6c
 [] raw_pci_read+0x3d/0x45
 [] __ioremap+0xb1/0x16b
 [] acpi_ex_system_memory_space_handler+0xdd/0x210
 [] acpi_ex_system_memory_space_handler+0x0/0x210
 [] acpi_ev_address_space_dispatch+0x127/0x168
 [] acpi_ex_access_region+0x1a5/0x1b7
 [] acpi_ex_field_datum_io+0x10b/0x193
 [] acpi_ns_search_one_scope+0x12/0x37
 [] acpi_ns_search_and_enter+0xf8/0x159
 [] acpi_ex_extract_from_field+0x98/0x221
 [] acpi_ut_allocate_object_desc_dbg+0x29/0x58
 [] acpi_ut_create_internal_object_dbg+0x15/0x67
 [] acpi_ex_read_data_from_field+0x108/0x136
 [] acpi_ex_resolve_node_to_value+0x145/0x1c0
 [] acpi_ex_resolve_to_value+0x202/0x20c
 [] acpi_ex_resolve_operands+0x1e1/0x4aa
 [] acpi_ds_exec_end_op+0xa7/0x3ae
 [] acpi_ps_parse_loop+0x546/0x6f8
 [] acpi_ps_parse_aml+0x5f/0x222
 [] acpi_ps_execute_method+0x10a/0x1a7
 [] acpi_ns_evaluate+0x90/0xe4
 [] acpi_ns_init_one_device+0x72/0xad
 [] acpi_ns_walk_namespace+0x94/0x114
 [] acpi_ns_initialize_devices+0x80/0xb3
 [] acpi_ns_init_one_device+0x0/0xad
 [] acpi_initialize_objects+0x28/0x3a
 [] acpi_init+0x77/0x21f
 [] kernel_init+0x97/0x1d1
 [] schedule_tail+0xe/0x39
 [] ret_from_fork+0x6/0x1c
 [] kernel_init+0x0/0x1d1
 [] kernel_init+0x0/0x1d1
 [] kernel_thread_helper+0x7/0x10
 ===
---[ end trace ca143223eefdc828 ]---

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patches for mips qemu target needed for stable.

[Ralf Baechle]

On Mon, Feb 25, 2008 at 10:36:59AM +0900, Samuel Masham wrote:

> Hi Stable team,
> 
> The mips build for qemu (and possibly other targets) crashes when
> doing any irq probe.
> 
> Specifically this happens on boot when brining up the ne driver.
> 
> This is fixed by the following two patches from linus's tree
> 
> 46f4f8f665080900e865392f4b3593be463bf0d8 - IRQ_NOPROBE helper functions
> 24649c00ca334955ac7d8a79f5a7834fc7ea441d - MIPS: Mark all but i8259
> interrupts as no-probe.
> 
> They have no impact on any other architecture so I hope are simple to
> include in the stable tree.

ACK.

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Brad Rosser]

On Mon, Feb 25, 2008 at 3:34 AM, Borislav Petkov
<[EMAIL PROTECTED]> wrote:
> On Sun, Feb 24, 2008 at 03:38:34PM +1000, Brad Rosser wrote:
> >
> > There's nothing in the bios that allows me to move one away from
> > the other.  I can 'reserve' or block IRQs, but that only shifts them
> > both to another interrupt.
>
>  well the driver probes the bios for that data and assigns the irq line it 
> gets
>  from it.

Oh.  I thought from all the 'IRQ routing/balancing' and the like in the
kernel there might be a way to switch things around, give the
Realtek driver a different IRQ than the one being used by the ide driver.
Just my crossed-fingers hope.

>  Can you please send me your whole boot log of 2.6.25-rc2? Thanks.

It's attached as file 'dmesg.bug.out'.

>  since your cdrom seems to be hda from what i've seen above, try booting with
>  'hda=noprobe' or maybe 'hda=none' to see which one turns the probing off for
>  you. See Documentation/ide.txt for details.

I tried both options, but in both cases there was no difference; the ide_cd_mod
module was still loaded and the 'confused' message still popped up.

I did four boots/tests of the 2.6.25-rc2 kernel, with and without those
boot parameters ... on all four I had the 'confused' message several times:

hda: cdrom_newpc_intr: The drive appears confused (ireason = 0x01).
Trying to recover by ending request.

but in one - the boot with hda=noprobe - I got pages of these
error messages right after:

hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: status timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ATAPI reset complete
hda: cdrom_decode_status: status=0xc0 { Busy }
ide: failed opcode was: unknown
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete
...

and the system essentially hung.  I don't know if that was due to the
'hda=noprobe' or if that extra sensitivity is seen only every now and then.

Bart wrote:

> Does the following patch help?
>
> [ It makes ireason handling for REQ_TYPE_ATA_PC requests be the same as
> for other request types so "ireason == 1" quirk is used if needed. ]

I tried to apply the patch but failed; I probably did something wrong.
I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c'
and ran 'patch --dry-run -b -p1 < ../bart_patch'.  This is part of my script
log:

root:/usr/src/linux-2.6.25-rc2# pwd
/usr/src/linux-2.6.25-rc2
root:/usr/src/linux-2.6.25-rc2# cat ../bart_patch
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -670,8 +670,8 @@ static void cdrom_buffer_sectors (ide_dr
 * and attempt to recover if there are problems.  Returns  0 if everything's
...
...
root:/usr/src/linux-2.6.25-rc2# patch --dry-run -b -p1 < ../bart_patch
patching file drivers/ide/ide-cd.c
Hunk #1 FAILED at 670.
Hunk #2 FAILED at 701.
Hunk #3 FAILED at 1074.
Hunk #4 FAILED at 1104.
4 out of 4 hunks FAILED -- saving rejects to file drivers/ide/ide-cd.c.rej

Since it found drivers/ide/ide-cd.c I guess I got the '-p' level right (?),
and that's about the sum total of my 'patch' experience to date.
Sorry.  Can you tell me what I did wrong?

Cheers,


Brad


dmesg.bug.out
Description: Binary data

[PATCH] kernel-doc: set verbose mode via environment

[Randy Dunlap]

From: Randy Dunlap <[EMAIL PROTECTED]>

Allow setting environment variable "KERNEL_DOC_VERBOSE=1" to enable
verbose mode in scripts/kernel-doc.  Useful for getting more
info and warnings from kernel-doc.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 scripts/kernel-doc |4 
 1 file changed, 4 insertions(+)

--- linux-2.6.25-rc3.orig/scripts/kernel-doc
+++ linux-2.6.25-rc3/scripts/kernel-doc
@@ -247,6 +247,10 @@ my ($function, %function_table,%paramete
 my ($type,$declaration_name,$return_type);
 my ($newsection,$newcontents,$prototype,$filelist, $brcount, %source_map);
 
+if (defined($ENV{'KERNEL_DOC_VERBOSE'})) {
+   $verbose = "$ENV{'KERNEL_DOC_VERBOSE'}";
+}
+
 # Generated docbook code is inserted in a template at a point where
 # docbook v3.1 requires a non-zero sequence of RefEntry's; see:
 # http://www.oasis-open.org/docbook/documentation/reference/html/refentry.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] md: fix integer as NULL pointer warnings in md.c

[Harvey Harrison]

drivers/md/md.c:734:16: warning: Using plain integer as NULL pointer
drivers/md/md.c:1115:16: warning: Using plain integer as NULL pointer

Add some braces to match the else-block as well.

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 drivers/md/md.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 7da6ec2..2879f60 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -731,9 +731,9 @@ static int super_90_load(mdk_rdev_t *rdev, mdk_rdev_t 
*refdev, int minor_version
else
rdev->desc_nr = sb->this_disk.number;
 
-   if (refdev == 0)
+   if (!refdev) {
ret = 1;
-   else {
+   } else {
__u64 ev1, ev2;
mdp_super_t *refsb = 
(mdp_super_t*)page_address(refdev->sb_page);
if (!uuid_equal(refsb, sb)) {
@@ -1112,9 +1112,9 @@ static int super_1_load(mdk_rdev_t *rdev, mdk_rdev_t 
*refdev, int minor_version)
else
rdev->desc_nr = le32_to_cpu(sb->dev_number);
 
-   if (refdev == 0)
+   if (!refdev) {
ret = 1;
-   else {
+   } else {
__u64 ev1, ev2;
struct mdp_superblock_1 *refsb = 
(struct mdp_superblock_1*)page_address(refdev->sb_page);
-- 
1.5.4.2.200.g99e75



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] smack: fix integer as NULL pointer warning in smack_lsm.c

[Harvey Harrison]

security/smack/smack_lsm.c:1257:16: warning: Using plain integer as NULL pointer

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 security/smack/smack_lsm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 770eb06..40010fa 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -1254,7 +1254,7 @@ static void smack_set_catset(char *catset, struct 
netlbl_lsm_secattr *sap)
int rc;
int byte;
 
-   if (catset == 0)
+   if (!catset)
return;
 
sap->flags |= NETLBL_SECATTR_MLS_CAT;
-- 
1.5.4.2.200.g99e75


>From 8c1fd96327f5c99c68b44da78ae8a5ac650f78f2 Mon Sep 17 00:00:00 2001
From: Harvey Harrison <[EMAIL PROTECTED]>
Date: Sun, 24 Feb 2008 17:27:20 -0800
Subject: [PATCH] md: fix integer as NULL pointer warnings in md.c

drivers/md/md.c:734:16: warning: Using plain integer as NULL pointer
drivers/md/md.c:1115:16: warning: Using plain integer as NULL pointer

Add some braces to match the else-block as well.

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 drivers/md/md.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 7da6ec2..2879f60 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -731,9 +731,9 @@ static int super_90_load(mdk_rdev_t *rdev, mdk_rdev_t 
*refdev, int minor_version
else
rdev->desc_nr = sb->this_disk.number;
 
-   if (refdev == 0)
+   if (!refdev) {
ret = 1;
-   else {
+   } else {
__u64 ev1, ev2;
mdp_super_t *refsb = 
(mdp_super_t*)page_address(refdev->sb_page);
if (!uuid_equal(refsb, sb)) {
@@ -1112,9 +1112,9 @@ static int super_1_load(mdk_rdev_t *rdev, mdk_rdev_t 
*refdev, int minor_version)
else
rdev->desc_nr = le32_to_cpu(sb->dev_number);
 
-   if (refdev == 0)
+   if (!refdev) {
ret = 1;
-   else {
+   } else {
__u64 ev1, ev2;
struct mdp_superblock_1 *refsb = 
(struct mdp_superblock_1*)page_address(refdev->sb_page);
-- 
1.5.4.2.200.g99e75



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Genirq and CPU isolation

[Randy Dunlap]

On Fri, 22 Feb 2008 22:19:18 -0800 Max Krasnyansky wrote:

Hi Max,

> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 438a014..e74db94 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -488,6 +491,26 @@ void free_irq(unsigned int irq, void *dev_id)
>  }
>  EXPORT_SYMBOL(free_irq);
>  
> +#ifndef CONFIG_AUTO_IRQ_AFFINITY
> +/**
> + * Generic version of the affinity autoselector.
> + * Called under desc->lock from setup_irq().
> + * btw Should we rename this to select_irq_affinity() ?
> + */

Please don't begin comment blocks with "/**" unless they are in
kernel-doc format.  (See Documentation/kernel-doc-nano-HOWTO.txt
for details of it.)

> +int select_smp_affinity(unsigned int irq)
> +{
> + cpumask_t usable_cpus;
> +
> + if (!irq_can_set_affinity(irq))
> + return 0;
> +
> + cpus_andnot(usable_cpus, cpu_online_map, cpu_isolated_map);
> + irq_desc[irq].affinity = usable_cpus;
> + irq_desc[irq].chip->set_affinity(irq, usable_cpus);
> + return 0;
> +}
> +#endif
> +
>  /**
>   *   request_irq - allocate an interrupt line
>   *   @irq: Interrupt line to allocate

This one is in kernel-doc format.

---
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86_64: make amd quad core 8 socket system not be clustered_box v2

[Yinghai Lu]

On Sunday 24 February 2008 03:00:52 pm Yinghai Lu wrote:
> On Sunday 24 February 2008 04:29:03 am Andi Kleen wrote:
> > On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
> > > 
> > > quad core 8 socket system will have apic id lifting.the apic id range 
> > > could
> > > be [4, 0x23]. and apic_is_clustered_box will think that need to three 
> > > clusters
> > > and that is large than 2. So it is treated as clustered_box.
> > 
> > Ok I see you chose the quick hack over doing it properly ...
> > 
> > > 
> > > and will get
> > > 
> > > Marking TSC unstable due to TSCs unsynchronized
> > > 
> > > even the CPUs have X86_FEATURE_CONSTANT_TSC set.
> > 
> > I doubt that will do the right thing on AMD based vSMP,
> > which also required the cluster check on AMD iirc.
> > 
> > Cc'ed Kiran/Shai. damage has already hit x86 tree I believe.
> 
> do you have bootlog for these box?
> 
> IBM summit2, Unisys es7, and system from scalemp..
> 
> DMI could tell the difference?

i produced one patch against linus tree. but it can not be applied to 
x86/testing

x86/testing has
obj-$(CONFIG_PARAVIRT)  += vsmp_64.o

so my question: is the vsmp the real HW or just in paravirt?

YH



[PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v3

quad core 8 socket system will have apic id lifting.the apic id range could
be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
and that is large than 2. So it is treated as clustered_box.

and will get

Marking TSC unstable due to TSCs unsynchronized

even the CPUs have X86_FEATURE_CONSTANT_TSC set.

this patch will check if the cpu is from AMD.

also vsmp still need that checking...

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 4eb5ce8..2bec799 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -60,7 +60,7 @@ obj-$(CONFIG_KEXEC)   += relocate_kernel_$(BITS).o 
crash.o
 obj-$(CONFIG_CRASH_DUMP)   += crash_dump_$(BITS).o
 obj-$(CONFIG_X86_NUMAQ)+= numaq_32.o
 obj-$(CONFIG_X86_SUMMIT_NUMA)  += summit_32.o
-obj-$(CONFIG_X86_VSMP) += vsmp_64.o
+obj-y  += vsmp_64.o
 obj-$(CONFIG_KPROBES)  += kprobes.o
 obj-$(CONFIG_MODULES)  += module_$(BITS).o
 obj-$(CONFIG_ACPI_SRAT)+= srat_32.o
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index d8d03e0..1427ec3 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1180,9 +1180,20 @@ __cpuinit int apic_is_clustered_box(void)
 {
int i, clusters, zeros;
unsigned id;
-   u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
+   u16 *bios_cpu_apicid;
DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
 
+   /*
+* there is not this kind of box with AMD CPU yet.
+* Some AMD box with quadcore cpu and 8 sockets apicid
+* will be [4, 0x23] or [8, 0x27] could be thought to
+* have three apic_clusters. So go out early.
+* vsmp box still need checking...
+*/
+   if (!is_vsmp_box() && (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
+   return 0;
+
+   bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
bitmap_zero(clustermap, NUM_APIC_CLUSTERS);
 
for (i = 0; i < NR_CPUS; i++) {
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index d971210..2780df1 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -16,19 +16,35 @@
 #include 
 #include 
 
+static int vsmp = -1;
+
+__cpuinit int is_vsmp_box(void)
+{
+   if (vsmp != -1)
+   return vsmp;
+
+   vsmp = 0;
+   if (!early_pci_allowed())
+   return vsmp;
+
+   /* Check if we are running on a ScaleMP vSMP box */
+   if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
+(PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL << 16)))
+   vsmp = 1;
+
+   return vsmp;
+}
+
+#ifdef CONFIG_X86_VSMP
 static int __init vsmp_init(void)
 {
void *address;
unsigned int cap, ctl;
 
-   if (!early_pci_allowed())
+   if (!vsmp)
return 0;
 
-   /* Check if we are running on a ScaleMP vSMP box */
-   if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
-PCI_VENDOR_ID_SCALEMP) ||
-   (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
-PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
+   if (!early_pci_allowed())
return 0;
 
/* set vSMP magic bits to indicate vSMP capable kernel */
@@ -50,3 +66,4 @@ static int __init vsmp_init(void)
 }
 
 core_initcall(vsmp_init);
+#endif
diff --git a/include/asm-x86/apic.h b/include/asm-x86/apic.h
index bcfc07f..d69f596 100644
--- a/include/asm-x86/apic.h
+++ b/include/asm-x86/apic.h
@@ -130,6 +130,7 @@ extern u8 setup_APIC_eilvt_mce(u8 vector, u8 msg_type, u8 
mask);
 extern u8 setup_APIC_eilvt_ibs(u8 vector, u8 

RE: [PATCH 03/10] PCI: AMD SATA IDE mode quirk

[Cai, Crane]

> On Fri, Feb 22, 2008 at 01:49:20PM +0800, Cai, Crane wrote:
> > > On Thu, Feb 21, 2008 at 03:47:33PM -0800, Greg 
> Kroah-Hartman wrote:
> > > > +static void __devinit quirk_amd_ide_mode(struct pci_dev *pdev)
> > > >  {
> > > > -   /* set sb600 sata to ahci mode */
> > > > -   if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> > > > -   u8 tmp;
> > > > +   /* set sb600/sb700/sb800 sata to ahci mode */
> > > > +   u8 tmp;
> > > >  
> > > > +   pci_read_config_byte(pdev, PCI_CLASS_DEVICE, );
> > > > +   if (tmp == 0x01) {
> > > > pci_read_config_byte(pdev, 0x40, );
> > > 
> > > This seems like a dis-improvement.  Why are we reading a 
> config byte 
> > > for something we already have in the pci_dev?
> > > Why are we now checking against 0x01 instead of a 
> symbolic constant?  
> > > Why are we no longer checking that this is PCI_BASE_CLASS_STORAGE?
> > It is a quirk. In pci_ids.h did have PCI_CLASS_STORAGE_IDE and 
> > PCI_BASE_CLASS_STORAGE, these can not represent the right 
> situation we 
> > want to check. 0x01 represents PCI_CLASS_STORAGE_IDE last 2 
> bit. Also 
> > because it is a quirk, I do not think we need to change 
> pci_ids.h. So 
> > 0x01 used.
> 
> You haven't explained what is wrong with the original code:
> 
>   if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> 

When resume, this pdev->class is quirked, however BIOS has modified pci 
configuration too. Inconsistance occurs.

> > > Nothing in the changelog entry suggests why we now need 
> FIXUP_RESUME 
> > > entries when we didn't before.
> > > 
> > PCI configuration space will be changed by BIOS and then in 
> pci init 
> > and restore. So resume also needed.
> 
> That information needed to be in the changelog.

This info, is a normal info. If maintainer need us to added in source code. I 
preferred too. 
> --
> Intel are signing my paycheques ... these opinions are still 
> mine "Bill, look, we understand that you're interested in 
> selling us this operating system, but compare it to ours.  We 
> can't possibly take such a retrograde step."
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.25-rc3: Reported regressions from 2.6.24

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.24 reported since
2.6.25-rc1 was released, for which there are no fixes in the mainline 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.24, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.


Listed regressions statistics:

  Date  Total  Pending  Unresolved
  
  2008-02-25   90   51  39
  2008-02-17       61       45          37


Unresolved regressions
--

Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9938
Subject : building fails on lguest
Submitter   : Cedric OLLIVIER <[EMAIL PROTECTED]>
Date: 2008-02-11 15:34


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9954
Subject : ipw3945: not only it periodically dies, it also BUG()s
Submitter   : Pavel Machek <[EMAIL PROTECTED]>
Date: 2008-02-05 22:44
References  : http://lkml.org/lkml/2008/2/5/453
Handled-By  : Chatre, Reinette <[EMAIL PROTECTED]>


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9958
Subject : parisc compile error
Submitter   : Adrian Bunk <[EMAIL PROTECTED]>
Date: 2008-02-08 01:12
References  : http://lkml.org/lkml/2008/2/7/572
Handled-By  : Kyle McMartin <[EMAIL PROTECTED]>


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9962
Subject : mount: could not find filesystem
Submitter   : Kamalesh Babulal <[EMAIL PROTECTED]>
Date: 2008-02-12 14:34
References  : http://lkml.org/lkml/2008/2/12/91
Handled-By  : Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
  Yinghai Lu <[EMAIL PROTECTED]>


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9966
Subject : kernel BUG at kernel/power/snapshot.c:464!
Submitter   : Jeff Mahoney <[EMAIL PROTECTED]>
Date: 2008-02-08 20:03
References  : http://lkml.org/lkml/2008/2/8/331
Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9978
Subject : 2.6.25-rc1: volanoMark 45% regression
Submitter   : Zhang, Yanmin <[EMAIL PROTECTED]>
Date: 2008-02-13 10:30
References  : http://lkml.org/lkml/2008/2/13/128
Handled-By  : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
  Balbir Singh <[EMAIL PROTECTED]>


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9980
Subject : 2.6.25-rc1 on Sun Ultra 40
Submitter   : Jasper Bryant-Greene <[EMAIL PROTECTED]>
Date: 2008-02-13 12:25
References  : http://lkml.org/lkml/2008/2/13/181
Handled-By  : Yinghai Lu <[EMAIL PROTECTED]>


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9983
Subject : PROBLEM: 2.6.25-rc1-git2 freezes when accessing external USB 
hard disk (ehci-hcd)
Submitter   : Linas Žvirblis <[EMAIL PROTECTED]>
Date: 2008-02-13 22:38
References  : http://lkml.org/lkml/2008/2/13/566


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9984
Subject : problem with starting 2.6.25-rc1 and latest git
Submitter   : Mariusz Kozlowski <[EMAIL PROTECTED]>
Date: 2008-02-13 23:16
References  : http://lkml.org/lkml/2008/2/13/587


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9992
Subject : 2.6.24-git: kmap_atomic() WARN_ON()
Submitter   : Thomas Gleixner <[EMAIL PROTECTED]>
Date: 2008-02-07 00:58
References  : http://lkml.org/lkml/2008/2/6/451
  http://lkml.org/lkml/2007/1/14/38


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=9995
Subject : 2.6.25-rc1 regression - backlight controlls do not work - 
ThinkPad T61
Submitter   : Lukas Hejtmanek <[EMAIL PROTECTED]>
Date: 2008-02-15 04:51
Handled-By  : Zhang Rui <[EMAIL PROTECTED]>


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=10003
Subject : hda_intel: balance control does not work correctly
Submitter   : Frans Pop <[EMAIL PROTECTED]>
Date: 2008-02-16 09:58


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=10011
Subject : The computer is blocked when X is started
Submitter   : François Valenduc <[EMAIL PROTECTED]>
Date: 2008-02-17 06:28
Handled-By  : Thomas Gleixner <[EMAIL PROTECTED]>


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=10012
Subject : 2.6.24-git4+ regression
Submitter   : Lukas Hejtmanek <[EMAIL PROTECTED]>
Date: 2008-01-30 14:56
References  : http://lkml.org/lkml/2008/1/30/254
Handled-By  : Ingo Molnar <[EMAIL PROTECTED]>
  Srivatsa Vaddagiri <[EMAIL PROTECTED]>


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=10015
Subject 

2.6.24 patches for mips qemu target needed for stable.

[Samuel Masham]

Hi Stable team,

The mips build for qemu (and possibly other targets) crashes when
doing any irq probe.

Specifically this happens on boot when brining up the ne driver.

This is fixed by the following two patches from linus's tree

46f4f8f665080900e865392f4b3593be463bf0d8 - IRQ_NOPROBE helper functions
24649c00ca334955ac7d8a79f5a7834fc7ea441d - MIPS: Mark all but i8259
interrupts as no-probe.

They have no impact on any other architecture so I hope are simple to
include in the stable tree.

Thanks

Samuel

ps: Included below for reference but gmail will probably mangle the
white spaces...

commit 46f4f8f665080900e865392f4b3593be463bf0d8
Author: Ralf Baechle <[EMAIL PROTECTED]>
Date:   Fri Feb 8 04:22:01 2008 -0800

IRQ_NOPROBE helper functions

Probing non-ISA interrupts using the handle_percpu_irq as their handle_irq
method may crash the system because handle_percpu_irq does not check
IRQ_WAITING.  This for example hits the MIPS Qemu configuration.

This patch provides two helper functions set_irq_noprobe and
set_irq_probe to
set rsp.  clear the IRQ_NOPROBE flag.  The only current caller is MIPS code
but this really belongs into generic code.

As an aside, interrupt probing these days has become a mostly
obsolete if not
dangerous art.  I think Linux interrupts should be changed to default to
non-probing but that's subject of this patch.

Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Acked-and-tested-by: Rob Landley <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

diff --git a/include/linux/irq.h b/include/linux/irq.h
index a19b381..bfd9efb 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -367,6 +367,9 @@ set_irq_chained_handler(unsigned int irq,
__set_irq_handler(irq, handle, 1, NULL);
 }

+extern void set_irq_noprobe(unsigned int irq);
+extern void set_irq_probe(unsigned int irq);
+
 /* Handle dynamic irq creation and destruction */
 extern int create_irq(void);
 extern void destroy_irq(unsigned int irq);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 10e0066..cc54c62 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -589,3 +589,39 @@ set_irq_chip_and_handler_name(unsigned int irq,
struct irq_chip *chip,
set_irq_chip(irq, chip);
__set_irq_handler(irq, handle, 0, name);
 }
+
+void __init set_irq_noprobe(unsigned int irq)
+{
+   struct irq_desc *desc;
+   unsigned long flags;
+
+   if (irq >= NR_IRQS) {
+   printk(KERN_ERR "Trying to mark IRQ%d non-probeable\n", irq);
+
+   return;
+   }
+
+   desc = irq_desc + irq;
+
+   spin_lock_irqsave(>lock, flags);
+   desc->status |= IRQ_NOPROBE;
+   spin_unlock_irqrestore(>lock, flags);
+}
+
+void __init set_irq_probe(unsigned int irq)
+{
+   struct irq_desc *desc;
+   unsigned long flags;
+
+   if (irq >= NR_IRQS) {
+   printk(KERN_ERR "Trying to mark IRQ%d probeable\n", irq);
+
+   return;
+   }
+
+   desc = irq_desc + irq;
+
+   spin_lock_irqsave(>lock, flags);
+   desc->status &= ~IRQ_NOPROBE;
+   spin_unlock_irqrestore(>lock, flags);
+}

commit 24649c00ca334955ac7d8a79f5a7834fc7ea441d
Author: Ralf Baechle <[EMAIL PROTECTED]>
Date:   Fri Feb 8 04:22:02 2008 -0800

MIPS: Mark all but i8259 interrupts as no-probe.

Use set_irq_noprobe() to mark all MIPS interrupts as non-probe.
Override that
default for i8259 interrupts.

Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Acked-and-tested-by: Rob Landley <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

diff --git a/arch/mips/kernel/i8259.c b/arch/mips/kernel/i8259.c
index 197d797..413bd1d 100644
--- a/arch/mips/kernel/i8259.c
+++ b/arch/mips/kernel/i8259.c
@@ -338,8 +338,10 @@ void __init init_i8259_irqs(void)

init_8259A(0);

-   for (i = I8259A_IRQ_BASE; i < I8259A_IRQ_BASE + 16; i++)
+   for (i = I8259A_IRQ_BASE; i < I8259A_IRQ_BASE + 16; i++) {
set_irq_chip_and_handler(i, _chip, handle_level_irq);
+   set_irq_probe(i);
+   }

setup_irq(I8259A_IRQ_BASE + PIC_CASCADE_IR, );
 }
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index d06e9c9..e3309ff 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -145,6 +145,11 @@ __setup("nokgdb", nokgdb);

 void __init init_IRQ(void)
 {
+   int i;
+
+   for (i = 0; i < NR_IRQS; i++)
+   set_irq_noprobe(i);
+
arch_init_irq();

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

Re: lockdep warnings in ipv6

[David Miller]

From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Sun, 24 Feb 2008 13:10:58 +0100 (CET)

> when doing IPv6 (ping6, ssh otherhost, etc.), lockdep spews a warning in 
> 2.6.25-rc2 on the target. CONFIG_..._FRAME_POINTER is off,

We reverted the change which causes this, and it results
in real bonafide lockups too :-)

commit 9ff566074689e3aed1488780b97714ec43ba361d
Author: David S. Miller <[EMAIL PROTECTED]>
Date:   Sun Feb 17 18:39:54 2008 -0800

Revert "[NDISC]: Fix race in generic address resolution"

This reverts commit 69cc64d8d92bf852f933e90c888dfff083bd4fc9.

It causes recursive locking in IPV6 because unlike other
neighbour layer clients, it even needs neighbour cache
entries to send neighbour soliciation messages :-(

We'll have to find another way to fix this race.

Signed-off-by: David S. Miller <[EMAIL PROTECTED]>

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 7bb6a9a..a16cf1e 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -834,12 +834,18 @@ static void neigh_timer_handler(unsigned long arg)
}
if (neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) {
struct sk_buff *skb = skb_peek(>arp_queue);
-
+   /* keep skb alive even if arp_queue overflows */
+   if (skb)
+   skb_get(skb);
+   write_unlock(>lock);
neigh->ops->solicit(neigh, skb);
atomic_inc(>probes);
-   }
+   if (skb)
+   kfree_skb(skb);
+   } else {
 out:
-   write_unlock(>lock);
+   write_unlock(>lock);
+   }
 
if (notify)
neigh_update_notify(neigh);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index c663fa5..8e17f65 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -368,6 +368,7 @@ static void arp_solicit(struct neighbour *neigh, struct 
sk_buff *skb)
if (!(neigh->nud_state_VALID))
printk(KERN_DEBUG "trying to ucast probe in 
NUD_INVALID\n");
dst_ha = neigh->ha;
+   read_lock_bh(>lock);
} else if ((probes -= neigh->parms->app_probes) < 0) {
 #ifdef CONFIG_ARPD
neigh_app_ns(neigh);
@@ -377,6 +378,8 @@ static void arp_solicit(struct neighbour *neigh, struct 
sk_buff *skb)
 
arp_send(ARPOP_REQUEST, ETH_P_ARP, target, dev, saddr,
 dst_ha, dev->dev_addr, NULL);
+   if (dst_ha)
+   read_unlock_bh(>lock);
 }
 
 static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Q: volatile vs barriers to access memory data changed by device DMA

[Eliot Blennerhassett]

Greetings,

Currently I have a driver that uses "volatile", which I want to remove.
As others have said "volatile is useless"
Heres the relevant source.
http://hg.alsa-project.org/alsa-driver/file/89222d702376/pci/asihpi/hpi6205.c

There's quite a bit written about barriers, but most seems to be assuming SMP 
situation or memory mapped devices. Not much about devices doing DMA.
I.e I have read Documentation/memory-barriers.txt, and some of the threads in 
lkml, but still am unsure.

The "volatile" is applied to structures that are either read or written by 
device DMA.  Certainly the driver in its current state doesn't work without 
volatile qualifier. (BTW the device doesn't use host interrupts)

Now, I want to get rid of the volatile, and replace it with ?some kind of 
barrier?

In the following, am I using the barriers correctly?

Note that structures ("interface") used for dma are allocated with 
dma_alloc_coherent()

1) Reading something updated by DMA
Here the volatile or barrier is needed or the loop gets optimised away.

=== current code
volatile struct bus_master_interface *interface;
while (interface->ack != OK) { 
delay(a short while)  
[ after X loops device changes interface->ack by dma ]
};

=== after conversion
struct bus_master_interface *interface;
while (interface->ack != OK) { 
delay(a short while);
rmb(); 
[ after X loops device changes interface->ack by dma ]
};

All I need is for the read of interface->ack in the loop not to be optimised 
away - is rmb() the appropriate incantation to achieve this?

2) Writing to memory, interrupt device
Need command to be in memory for device to read by DMA before device gets 
interrupted.

=== current code ===
volatile struct bus_master_interface *interface;
interface->cmd = command;
iowrite(device_interrupt, 1);
[device reads interface->cmd by dma]

=== after conversion ===
struct bus_master_interface *interface;
interface->cmd = command;
wmb();
iowrite(device_interrupt, 1);
[device reads interface->cmd by dma]

Is the wmb() a guarantee that the command will be in memory visible to the 
device when the driver informs it of a new command?
Is it even needed? I.e. does iowrite() effectively form a barrier?

regards

--
Eliot Blennerhassett
www.audioscience.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 2.6.25-rc2-git 1/2] atmel_tc library

[David Brownell]

> > > > Note that this won't be usable until the AT91 and AT32 platforms
> > > > incorporate patches to configure the relevant platform devices.
> > > > Those changes are probably 2.6.26 material.
> > 
> > More specifically (and all those patches are available now):
> > 
> >  - AT91 needs clocksource/clockevent support for the SAM9 PIT timer;
> >  - AVR32 needs more extensive clocksource/clockevent updates;
>
> Which reminds me...you were talking about a patch that adds oneshot
> support for the count/compare clocksource and more cleanups, but I
> don't think I've seen it...?

I avoid sending non-working patches, and hadn't made time to
work on that issue recently.


> Yes, getting the fundamental stuff into mainline now would help a lot.

Or at least, towards the front of the merge queue, ahead of
the various platform-specific patches.


> But I was thinking about Linus' suggestions that we exploit the
> distributed nature of git and do cross-tree merges to synchronize
> changes to common code.
>
> Setting up a separate git tree would allow the changes to go into the
> arm tree without littering it with possibly unstable avr32 changes as
> well, and it would allow me to merge them and put more stuff on top.

Doing that with ARM patches is Russell's call; he hasn't been too
keen on merging from non-Linus GIT trees when that came up before.


> > > > +#define ATMEL_TC_BMR   0xc4/* TC Block Mode Register */
> > > > +#define ATMEL_TC_TC0XC0S   (3 << 0)/* external clock 0 
> > > > source */
> > > > +#defineATMEL_TC_TC0XC0S_TCLK0  (0 << 0)
> > >
> > > Hmm. Indentation using spaces? I didn't know you were into that sort of
> > > thing ;-)
> > 
> > It's way better than indenting off the right margin of the page!
>
> I've never really seen the point of indenting those defines at all.

Without them, it's harder to discern the logical structure of
all the various bitfields and their contents.


> > > Anyway, my main issue is that I think we should add a data structure
> > > with information about each device, similar to struct ssc_device in the
> > > atmel-ssc driver. How about something like this?
> > >
> > > struct atmel_tc_block {
> > >   void __iomem*regs;  /* non-NULL when busy */
> > >   struct platform_device  *pdev;
> > >   struct clk  *clk[3];
> > >   struct list_headnode;
> > > };
> > 
> > And per-channel IRQs too...
>
> I thought about that, but while the driver can safely call clk_enable()
> on the same clock several times, I'm not sure if it's such a great idea
> to call request_irq() on the same interrupt several times. So the
> driver probably needs to know how many irqs there really are and might
> as well use platform_get_irq() to find out.

I thought the whole point of passing the clocks was to avoid needing
to ask for them!!  If trying one or three platform_get_irq() calls is
OK, then surely trying one or three clk_get() calls is also OK...

- Dave


> > Well, if you want to take these patches off my hands and then be
> > responsible for merging them upstream, I won't object.  :)
>
> I can do that.
>
> It's getting late around here...I'll reply to your other mail tomorrow.
>
> Haavard
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.25-rc2-git8 fails to boot on 486 due to TSC breakage

[H. Peter Anvin]

Mikael Pettersson wrote:


Here's how the breakage occurs:
1. arch/x86/kernel/tsc_32.c:tsc_init() sees !cpu_has_tsc,
   so bails and calls setup_clear_cpu_cap(X86_FEATURE_TSC).
2. include/asm-x86/cpufeature.h:setup_clear_cpu_cap(bit) clears
   the bit in boot_cpu_data and sets it in cleared_cpu_caps
3. arch/x86/kernel/cpu/common.c:identify_cpu() XORs all caps
   in with cleared_cpu_caps
   HOWEVER, at this point c->x86_capability correctly has TSC
   Off, cleared_cpu_caps has TSC On, so the XOR incorrectly
   sets TSC to On in c->x86_capability, with disastrous results.

The real bug is that clearing bits with XOR only works if the
bits are known to be 1 prior to the XOR, and that's not true here.

A simple fix is to convert the XOR to AND-NOT instead. The following
patch does that, and allows my 486 to boot 2.6.25-rc kernels again.



Please fix it in both places.  Using XOR instead of AND-NOT is a bug, 
plain and simple.


-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.25-rc2-mm1][2.6.25-rc3] Remove argv_len from struct linux_binprm

[Tetsuo Handa]

I noticed that 2.6.24.2 calculates bprm->argv_len at do_execve().
But it doesn't update bprm->argv_len after
"remove_arg_zero() + copy_strings_kernel()" at load_script() etc.

audit_bprm() is called from search_binary_handler()
and search_binary_handler() is called from load_script() etc.
Thus, I think the condition check

  if (bprm->argv_len > (audit_argv_kb << 10))
  return -E2BIG;

in audit_bprm() might return wrong result
when strlen(removed_arg) != strlen(spliced_args).
Why not update bprm->argv_len at load_script() etc. ?


By the way, 2.6.25-rc3 seems to not doing the condition check.
Is the field bprm->argv_len no longer needed?

Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
 fs/exec.c   |3 ---
 include/linux/binfmts.h |1 -
 2 files changed, 4 deletions(-)

--- linux-2.6.25-rc3.orig/fs/exec.c
+++ linux-2.6.25-rc3/fs/exec.c
@@ -1274,7 +1274,6 @@ int do_execve(char * filename,
 {
struct linux_binprm *bprm;
struct file *file;
-   unsigned long env_p;
int retval;
 
retval = -ENOMEM;
@@ -1322,11 +1321,9 @@ int do_execve(char * filename,
if (retval < 0)
goto out;
 
-   env_p = bprm->p;
retval = copy_strings(bprm->argc, argv, bprm);
if (retval < 0)
goto out;
-   bprm->argv_len = env_p - bprm->p;
 
retval = search_binary_handler(bprm,regs);
if (retval >= 0) {
--- linux-2.6.25-rc3.orig/include/linux/binfmts.h
+++ linux-2.6.25-rc3/include/linux/binfmts.h
@@ -48,7 +48,6 @@ struct linux_binprm{
unsigned interp_flags;
unsigned interp_data;
unsigned long loader, exec;
-   unsigned long argv_len;
 };
 
 #define BINPRM_FLAGS_ENFORCE_NONDUMP_BIT 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/

Re: [patch 2.6.25-rc2-git 1/2] atmel_tc library

[Haavard Skinnemoen]

On Sun, 24 Feb 2008 14:55:27 -0800
David Brownell <[EMAIL PROTECTED]> wrote:

> On Sun, 24 Feb 2008 18:45:54 +0100
> Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 22 Feb 2008 17:23:23 -0800
> > David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > > Note that this won't be usable until the AT91 and AT32 platforms
> > > incorporate patches to configure the relevant platform devices.
> > > Those changes are probably 2.6.26 material.
> 
> More specifically (and all those patches are available now):
> 
>  - AT91 needs clocksource/clockevent support for the SAM9 PIT timer;
>  - AVR32 needs more extensive clocksource/clockevent updates;

Which reminds me...you were talking about a patch that adds oneshot
support for the count/compare clocksource and more cleanups, but I
don't think I've seen it...?

I've probably messed things up enough that it won't apply cleanly
anymore, but if you just send me what you have, I'll rebase and fold it
as necessary.

>  - Both also need platform device setup;

Right. I think I've got both those patches.

> Merging these two patches before those is a perfectly safe NOP.

Right. I just want to get everything properly queued up before the
merge window opens.

> > I see the following possibilities:
> >   * I switch avr32 over to use the new code after it has been merged
> > into mainline. This means the new code won't be tested on avr32
> > until near the end of the next merge window -- not good.
> 
> Well, "more widely" tested.  We've both observed it to work; basically
> the same code has worked on AT91 for about a year now, too.

Sure, but a bit more exposure won't hurt.

> And that's why I suggest merging these parts, now that they're known to
> work on both architectures.  The arch-specific bits can follow at their
> own pace, neither one blocking the other.
> 
> >   * I forward the patches that switch avr32 over to Andrew so that they
> > can be included in -mm right after the tclib support. Not a bad
> > option, but I'm planning to do more AVR32 PM work before 2.6.26, so
> > there might be conflicts.
> 
> Conflicts there would be the easy part to deal with.  They're all
> specific to AVR32, and you can merge those in any convenient order.

Assuming the tclib stuff comes first, yes. I'm not worried about me
having to deal with conflicts, I'm worried about Andrew or Stephen
having to fix up my mess.

> >   * I take the whole thing through my avr32 git tree.
> 
> Doesn't work as smoothly for the AT91 side ... but Andrew Victor has
> very limited time any more for such stuff (these AT91 patches will
> go through him first then Russell) so I'm not sure any added delays
> there could hurt much.

Right. I was just mentioning it as one option.

> >   * I (or someone else) set up a new git tree for tclib + AT91 and
> > AVR32 platform support and ask Stephen to pull it into the -next
> > tree. Or, once it's stable, rmk and I can both pull it into our
> > respective trees. But that obviously means no rebasing and funny
> > games from that point on...
> >
> > I think the last option is the best one. What do you think?
> 
> In effect, I've had that last option as a series of quilt patches,
> and posting these two is the first step in that merge sequence...
> heck, they could merge right now into 2.6.25-rc3 and that would let
> the two arch series merge at their own paces.  (AVR32 direct from
> you, AT91 very indirectly through Andrew then Russell.)

Yes, getting the fundamental stuff into mainline now would help a lot.
But I was thinking about Linus' suggestions that we exploit the
distributed nature of git and do cross-tree merges to synchronize
changes to common code.

Setting up a separate git tree would allow the changes to go into the
arm tree without littering it with possibly unstable avr32 changes as
well, and it would allow me to merge them and put more stuff on top.
And if the patches are ready for mainline, there should be no need to
fix up the history of the "tclib" tree later, so it should be perfectly
safe to merge into several trees (assuming those trees don't rebase and
make them appear as different commits.)

> My personal priority is to get these patches into the merge queue(s)
> so that they're no longer sitting on my disks and so that when I
> want those platforms to have HRT and/or NO_HZ, it's already there. 

Which goes nicely along with my priority of reducing the overall power
consumption on avr32 :)

> > > +/* we "know" that there will be either one or two TC blocks */
> > > +static struct platform_device *blocks[2];
> >
> > You seem to know more about future Atmel chips than I do :-P
> 
> I only "know" about currently announced ones.  ;)

Yeah, I didn't actually check how many TC blocks are planned on other
chips. I just want this to be a bit future-proof.

> > I'm not a huge fan of such static limitations.
> 
> Me either, but at this point doing more than that seems to me
> to land in that "overengineering" 

[PATCH 6/6] block: fix shadowed variable warning in blk-map.c

[Harvey Harrison]

Introduced between 2.6.25-rc2 and -rc3
block/blk-map.c:154:14: warning: symbol 'bio' shadows an earlier one
block/blk-map.c:110:13: originally declared here

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 block/blk-map.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/block/blk-map.c b/block/blk-map.c
index 09f7fd0..f443c21 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -151,10 +151,10 @@ int blk_rq_map_user(struct request_queue *q, struct 
request *rq,
 */
if (len & queue_dma_alignment(q)) {
unsigned int pad_len = (queue_dma_alignment(q) & ~len) + 1;
-   struct bio *bio = rq->biotail;
+   struct bio *tail = rq->biotail;
 
-   bio->bi_io_vec[bio->bi_vcnt - 1].bv_len += pad_len;
-   bio->bi_size += pad_len;
+   tail->bi_io_vec[tail->bi_vcnt - 1].bv_len += pad_len;
+   tail->bi_size += pad_len;
rq->data_len += pad_len;
}
 
-- 
1.5.4.2.200.g99e75

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] smack: make functions static

[Harvey Harrison]

Introduced between 2.6.25-rc2 and -rc3
security/smack/smackfs.c:374:6: warning: symbol 'smk_unlbl_ambient' was not 
declared. Should it be static?

While here, take care of this one too.
security/smack/smackfs.c:341:6: warning: symbol 'smk_cipso_doi' was not 
declared. Should it be static?

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 security/smack/smackfs.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
index 358c92c..cb26951 100644
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -338,7 +338,7 @@ static const struct file_operations smk_load_ops = {
 /**
  * smk_cipso_doi - initialize the CIPSO domain
  */
-void smk_cipso_doi(void)
+static void smk_cipso_doi(void)
 {
int rc;
struct cipso_v4_doi *doip;
@@ -371,7 +371,7 @@ void smk_cipso_doi(void)
 /**
  * smk_unlbl_ambient - initialize the unlabeled domain
  */
-void smk_unlbl_ambient(char *oldambient)
+static void smk_unlbl_ambient(char *oldambient)
 {
int rc;
struct netlbl_audit audit_info;
-- 
1.5.4.2.200.g99e75


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] agp: fix shadowed variable warning in amd-k7-agp.c

[Harvey Harrison]

Introduced between 2.6.25-rc2 and -rc3
drivers/char/agp/amd-k7-agp.c:439:6: warning: symbol 'cap_ptr' shadows an 
earlier one
drivers/char/agp/amd-k7-agp.c:414:5: originally declared here

cap_ptr is never used again in this function, don't bother redeclaring.

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 drivers/char/agp/amd-k7-agp.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index d286699..96bdb92 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -436,8 +436,9 @@ static int __devinit agp_amdk7_probe(struct pci_dev *pdev,
   system controller may experience noise due to strong drive strengths
 */
if (agp_bridge->dev->device == PCI_DEVICE_ID_AMD_FE_GATE_7006) {
-   u8 cap_ptr=0;
struct pci_dev *gfxcard=NULL;
+
+   cap_ptr = 0;
while (!cap_ptr) {
gfxcard = pci_get_class(PCI_CLASS_DISPLAY_VGA<<8, 
gfxcard);
if (!gfxcard) {
-- 
1.5.4.2.200.g99e75


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

[PATCH 5/6] block: remove extern on function definition

[Harvey Harrison]

Intoduced between 2.6.25-rc2 and -rc3
block/blk-settings.c:319:12: warning: function 'blk_queue_dma_drain' with 
external linkage has definition

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 block/blk-settings.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 9a8ffdd..6200415 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -316,7 +316,7 @@ EXPORT_SYMBOL(blk_queue_stack_limits);
  * device can support otherwise there won't be room for the drain
  * buffer.
  */
-extern int blk_queue_dma_drain(struct request_queue *q,
+int blk_queue_dma_drain(struct request_queue *q,
   dma_drain_needed_fn *dma_drain_needed,
   void *buf, unsigned int size)
 {
-- 
1.5.4.2.200.g99e75


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] markers: make marker_debug static

[Harvey Harrison]

Introduced between 2.6.25-rc2 and -rc3
kernel/marker.c:31:11: warning: symbol 'marker_debug' was not declared. Should 
it be static?

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 kernel/marker.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/marker.c b/kernel/marker.c
index 50effc0..dc2eb12 100644
--- a/kernel/marker.c
+++ b/kernel/marker.c
@@ -28,7 +28,7 @@ extern struct marker __start___markers[];
 extern struct marker __stop___markers[];
 
 /* Set to 1 to enable marker debug output */
-const int marker_debug;
+static const int marker_debug;
 
 /*
  * markers_mutex nests inside module_mutex. Markers mutex protects the builtin
-- 
1.5.4.2.200.g99e75


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] xen: make blkif_getgeo static

[Harvey Harrison]

Introduced between 2.6.25-rc2 and -rc3
drivers/block/xen-blkfront.c:139:5: warning: symbol 'blkif_getgeo' was not 
declared. Should it be static?

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 drivers/block/xen-blkfront.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 9c6f3f9..ae7ee16 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -136,7 +136,7 @@ static void blkif_restart_queue_callback(void *arg)
schedule_work(>work);
 }
 
-int blkif_getgeo(struct block_device *bd, struct hd_geometry *hg)
+static int blkif_getgeo(struct block_device *bd, struct hd_geometry *hg)
 {
/* We don't have real geometry info, but let's at least return
   values consistent with the size of the device */
-- 
1.5.4.2.200.g99e75


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [spi-devel-general] [PATCH] atmel_spi: support zero length transfer

[Atsushi Nemoto]

On Fri, 22 Feb 2008 14:36:53 -0500, Ned Forrester <[EMAIL PROTECTED]> wrote:
> Or are you and Atsushi talking about using spi_transfer.delay_usecs
> *with* a zero length transfer to effectively put a delay between the
> assertion of CS and the start of the first clock?  If so, then I guess I
> missed the original point.  Sorry.

Yes.  I want to use zero length transfer with delay_usecs to achieve
CS-CLK delay for my funny device.  And I was too lazy to reject true
nop transfer.

---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: linux-next: Tree for Feb 24

[Kevin Winchester]

Rafael J. Wysocki wrote:
> On Monday, 25 of February 2008, Kevin Winchester wrote:
>> Rafael J. Wysocki wrote:
>>> On Sunday, 24 of February 2008, Kevin Winchester wrote:
>>>
>>>> Today was different - I attempted to suspend and resume from the console,
>>>> and the machine did not come back up.  I found the following in my log -
>>>> any help would be appreciated.
>>>>
>>>> Feb 24 13:59:56 alekhine kernel: [  456.497875] PM: Syncing filesystems 
>>>> ... done.
>>>> Feb 24 14:00:20 alekhine kernel: [  456.507273] Freezing user space 
>>>> processes ... (elapsed 0.00 seconds) done.
>>>> Feb 24 14:00:20 alekhine kernel: [  456.510447] Freezing remaining 
>>>> freezable tasks ... (elapsed 0.00 seconds) done.
>>>> Feb 24 14:00:20 alekhine kernel: [  456.510754] ACPI: Preparing to enter 
>>>> system sleep state S3
>>>> Feb 24 14:00:20 alekhine kernel: [  456.612370] Suspending console(s)
>>>> Feb 24 14:00:20 alekhine kernel: [  456.616254] sd 3:0:0:0: [sda] 
>>>> Synchronizing SCSI cache
>>>> Feb 24 14:00:20 alekhine kernel: [  456.616521] sd 3:0:0:0: [sda] Stopping 
>>>> disk
>>>> Feb 24 14:00:20 alekhine kernel: [  456.618221] ACPI: PCI interrupt for 
>>>> device :00:11.5 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [  456.630296] ACPI: PCI interrupt for 
>>>> device :00:10.4 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [  456.641085] ACPI: PCI interrupt for 
>>>> device :00:10.3 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [  456.651877] ACPI: PCI interrupt for 
>>>> device :00:10.2 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [  456.662716] ACPI: PCI interrupt for 
>>>> device :00:10.1 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [  456.673550] ACPI: PCI interrupt for 
>>>> device :00:10.0 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [  456.684385] ACPI: PCI interrupt for 
>>>> device :00:0f.1 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [  456.695056] ACPI: PCI interrupt for 
>>>> device :00:0f.0 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856] 5 locks held by bash/2929:
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856]  #0:  
>>>> (>mutex){--..}, at: [] sysfs_write_file+0x25/0xe3
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856]  #1:  (pm_mutex){--..}, 
>>>> at: [] enter_state+0xea/0x100
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856]  #2:  
>>>> (pm_sleep_rwsem){}, at: [] device_suspend+0x25/0x251
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856]  #3:  
>>>> (>update_lock#2){--..}, at: [] abituguru_suspend+0x13/0x18
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856]  #4:  (>lock){++..}, 
>>>> at: [] velocity_suspend+0x37/0x302
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856] irq event stamp: 19374
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856] hardirqs last  enabled at 
>>>> (19373): [] __mutex_unlock_slowpath+0xd5/0xef
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856] hardirqs last disabled at 
>>>> (19374): [] _spin_lock_irqsave+0xf/0x3c
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856] softirqs last  enabled at 
>>>> (18484): [] __do_softirq+0x99/0x9e
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856] softirqs last disabled at 
>>>> (18479): [] do_softirq+0x58/0xa8
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856] Pid: 2929, comm: bash Not 
>>>> tainted 2.6.25-rc2-next-20080224 #58
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856]  [] 
>>>> __schedule_bug+0x58/0x5f
>>>> Feb 24 14:00:20 alekhine kernel: [  456.705856]  [] 
>>>> schedule+0x67/0x3b3
>>> Well, could you check what's at schedule+0x67, please?
>> Is this how I would do this?  I tried schedule+0x67, but it just showed me 
>> the beginning of profile_hit.
>>
>> (gdb) l *(schedule+0x66)
>> 0xc0325b42 is in schedule (kernel/sched.c:3836).
>> 3831  * Test if we are atomic. Since do_exit() needs to call into
>> 3832  * schedule() atomically, we ignore that path for now.
>> 3833  * Otherwise, whine if we are scheduling when we should not be.
>> 3834  */
>> 3835 if (unlikely(in_atomic_preempt_off()) && 
>> unlikely(!prev->exit_state))
>> 3836 __s

Re: Nework Emulation with UML, bug 8895

[Andrew Morton]

On Sat, 23 Feb 2008 14:04:18 +0100 clowncoder <[EMAIL PROTECTED]> wrote:

> Hello,
> You can have a configured and running network inside a single linux machine,
> only one script command is enough. After the start of all the machine, a
> graphical representation of your topology helps your interactions with
> the network. This virtual network can be downloaded at http://clownix.net,
> I must warn you, it is a 350mega bz2 file-system that needs 4 giga on 
> the host.
> Very usefull for networking development in kernel as proved by bug 8895
> that has been found with the above tool:
> 
> The uncorrected bug 8895:
> 
> file:  /usr/src/linux-2.6.24.2/net/ipv6/ip6_fib.c  line  796:   
> "dst_free(>u.dst);"
> 
> --- /Comment From qmiao  2007-08-29 
> 23:33:07 /---
> 
> fib6_add
> ...
> 
> if (fn->leaf == NULL) {
> fn->leaf = rt;<--**-- rt is assigned to fn->leaf
> atomic_inc(>rt6i_ref);
> }
> ...
> err = fib6_add_rt2node(fn, rt, info); <-**- return -EEXIST
> ...
> (Here err was not null)
> ...
> if (err) {
> ...
> dst_free(>u.dst); <--**-- Actually rt is still in
> tree (fn->leaf = rt /* see above */)
> ...
> }
> 

Please cc netdev on net-related bug reports.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation

[Ahmed S. Darwish]

On Sun, Feb 24, 2008 at 06:26:53PM +0200, Ahmed S. Darwish wrote:
> On Sun, Feb 24, 2008 at 05:18:14PM +0100, Ingo Molnar wrote:
> 
> > I've picked up your patch into x86.git#testing (until Rusty picks it 
> > up), you can track it the following way:
> > 
> > http://people.redhat.com/mingo/x86.git/README
> > 
> > it has other lguest fixes as well - could you double-check that 
> > x86.git#testing works fine for you as-is? (i've just updated the git 
> > tree so it includes your fix as well)
> > 
> 
> Ofcourse. I'll send you the results by GMT night.
> 

This thread's main bug no longer appears. There's a new bug though,
but it looks nicer than the original ugly bug!. 

The new bug does *not* appear in mainline with the same patch. It's
a panic, but this time on the _guest_ side (which is the same host's
kernel).

[0.023996] CPU: Intel(R) Pentium(R) M processor 1500MHz stepping 05
[0.023996] Kernel panic - not syncing: Kernel compiled for Pentium+, 
requires TSC feature!
[0.023996] Pid: 0, comm: swapper Not tainted 2.6.25-rc2-00815-g3db3a05 #64
[0.024996]  [] panic+0x47/0x120
[0.024996]  [] lguest_power_off+0x0/0x20
[0.024996]  [] check_bugs+0x155/0x170
[0.024996]  [] start_kernel+0x22f/0x2d0
[0.024996]  [] unknown_bootoption+0x0/0x1f0
[0.024996]  [] lguest_restart+0x0/0x20
[0.024996]  [] lguest_restart+0x0/0x20
[0.024996]  [] lguest_init+0x282/0x290
[0.024996]  ===

I'll track it further in my first free time slot.

It seems lguest is very sensitive to x86 tree changes. Could it be 
included in a sort of automatic guest-boot testing, please ?

Thank you,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.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: arcmsr & areca-1660 - strange behaviour under heavy load

[Andrew Morton]

On Sat, 23 Feb 2008 12:20:12 +0100 (CET) Nikola Ciprich <[EMAIL PROTECTED]> 
wrote:

> Hi,
> 
> I've found strange problem either in arcmsr driver, or maybe in 
> areca-1660 card...
> When system on SAS discs RAID connected to areca-1660 card 
> gets under heavy I/O load, it gets unusable after some time. I can 100% 
> reproduce 
> this, although it needs quite speciffic conditions:
> It can be reproduced on 2x quad core machine, RAM has to be limited to 
> ~192MB to cause heavy paging.
> Only thing needed to cause the problem is to start loop doing kernel 
> compilation using make -j 8 - this loads the system heavily, because of 
> lack of memory. After few correct compile runs the system gets into 
> state when all programs including the basic ones (ls, cp, ..) start 
> crashing... dmesg (when it works) doesn't say anything strange...
> After reboot, the system is OK again.
> I have tested it on different motherboards, with different CPUs, RAMs(all 
> were properly tested with memtest), with two different areca cards and 
> different drives. I can't reproduce the problem on same hardware when 
> using different RAID card (ie adaptec). All testing systems were properly 
> cooled..
> I have tried all available areca firmwares, two different distributions 
> (oracle linux, and centos), and kernels ranging from distribution ones, to 
> last GIT snapshot.
> Could somebody please give me some hints on how to hunt this problem?
> Areca support doesn't seem to be very interested in the problem :-(

(cc's added)

Please get the machine into this state of memory exhaustion then take
copies of the output of the following, and send them via reply-to-all to
this email:

- cat /proc/meminfo

- cat /proc/slabinfo

- dmesg -c > /dev/null ; echo m > /proc/sysrq-trigger ; dmesg -c

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/

[2.6 patch] mm/vmstat.c: proper externs

[Adrian Bunk]

This patch adds proper extern declarations for five variables in 
include/linux/vmstat.h

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

---

 fs/proc/proc_misc.c|4 
 include/linux/vmstat.h |6 ++
 kernel/sysctl.c|2 +-
 mm/vmstat.c|1 +
 4 files changed, 8 insertions(+), 5 deletions(-)

b2c1dc15728c7470d3ea5aad9c1227131eb5fc3f diff --git a/fs/proc/proc_misc.c 
b/fs/proc/proc_misc.c
index 468805d..622d35b 100644
--- a/fs/proc/proc_misc.c
+++ b/fs/proc/proc_misc.c
@@ -222,7 +222,6 @@ static int meminfo_read_proc(char *page, char **start, 
off_t off,
 #undef K
 }
 
-extern const struct seq_operations fragmentation_op;
 static int fragmentation_open(struct inode *inode, struct file *file)
 {
(void)inode;
@@ -236,7 +235,6 @@ static const struct file_operations 
fragmentation_file_operations = {
.release= seq_release,
 };
 
-extern const struct seq_operations pagetypeinfo_op;
 static int pagetypeinfo_open(struct inode *inode, struct file *file)
 {
return seq_open(file, _op);
@@ -249,7 +247,6 @@ static const struct file_operations pagetypeinfo_file_ops = 
{
.release= seq_release,
 };
 
-extern const struct seq_operations zoneinfo_op;
 static int zoneinfo_open(struct inode *inode, struct file *file)
 {
return seq_open(file, _op);
@@ -346,7 +343,6 @@ static const struct file_operations proc_devinfo_operations 
= {
.release= seq_release,
 };
 
-extern const struct seq_operations vmstat_op;
 static int vmstat_open(struct inode *inode, struct file *file)
 {
return seq_open(file, _op);
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 75370ec..0970628 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -40,6 +40,12 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
NR_VM_EVENT_ITEMS
 };
 
+extern const struct seq_operations fragmentation_op;
+extern const struct seq_operations pagetypeinfo_op;
+extern const struct seq_operations zoneinfo_op;
+extern const struct seq_operations vmstat_op;
+extern int sysctl_stat_interval;
+
 #ifdef CONFIG_VM_EVENT_COUNTERS
 /*
  * Light weight per cpu counter implementation.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ffb687c..d78773d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -76,7 +77,6 @@ extern int sysctl_drop_caches;
 extern int percpu_pagelist_fraction;
 extern int compat_log;
 extern int maps_protect;
-extern int sysctl_stat_interval;
 extern int latencytop_enabled;
 
 /* Constants used for minimum and  maximum */
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 422d960..81a6d5f 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_VM_EVENT_COUNTERS
 DEFINE_PER_CPU(struct vm_event_state, vm_event_states) = {{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/