date:20050228

Dave Hansen <[EMAIL PROTECTED]> wrote:
>
> memory_present() is how each arch/subarch will tell sparsemem
>  and discontigmem where all of its memory is.  This is what
>  triggers sparse to go out and create its mappings for the memory,
>  as well as allocate the mem_map[].

There are cross-compilers at http://developer.osdl.org/dev/plm/cross_compile/

This also needs runtime testing on ppc64, does it not?


arch/ppc64/mm/numa.c:63: error: redefinition of `memory_present'
include/linux/mmzone.h:285: error: `memory_present' previously defined here
arch/ppc64/mm/numa.c: In function `memory_present':
arch/ppc64/mm/numa.c:65: error: `start' undeclared (first use in this function)
arch/ppc64/mm/numa.c:65: error: (Each undeclared identifier is reported only 
once
arch/ppc64/mm/numa.c:65: error: for each function it appears in.)
arch/ppc64/mm/numa.c:66: error: `end' undeclared (first use in this function)
arch/ppc64/mm/numa.c:65: warning: unused variable `start_addr'
arch/ppc64/mm/numa.c:66: warning: unused variable `end_addr'


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

 25-akpm/arch/ppc64/Kconfig   |   10 ++
 25-akpm/arch/ppc64/mm/numa.c |6 +++---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff -puN arch/ppc64/Kconfig~x86-abstract-discontigmem-setup-ppc64-fix 
arch/ppc64/Kconfig
--- 25/arch/ppc64/Kconfig~x86-abstract-discontigmem-setup-ppc64-fix 
2005-03-01 03:58:15.0 -0700
+++ 25-akpm/arch/ppc64/Kconfig  2005-03-01 03:58:15.0 -0700
@@ -203,6 +203,16 @@ config DISCONTIGMEM
bool "Discontiguous Memory Support"
depends on SMP && PPC_PSERIES
 
+config HAVE_MEMORY_PRESENT
+   bool
+   depends on DISCONTIGMEM
+   default y
+
+config NEED_NODE_MEMMAP_SIZE
+   bool
+   depends on DISCONTIGMEM
+   default y
+
 config NUMA
bool "NUMA support"
depends on DISCONTIGMEM
diff -puN arch/ppc64/mm/numa.c~x86-abstract-discontigmem-setup-ppc64-fix 
arch/ppc64/mm/numa.c
--- 25/arch/ppc64/mm/numa.c~x86-abstract-discontigmem-setup-ppc64-fix   
2005-03-01 03:58:37.0 -0700
+++ 25-akpm/arch/ppc64/mm/numa.c2005-03-01 03:59:15.0 -0700
@@ -62,10 +62,10 @@ void memory_present(int nid, unsigned lo
 unsigned long end_pfn)
 {
unsigned long i;
-   unsigned long start_addr = start << PAGE_SHIFT;
-   unsigned long end_addr = end << PAGE_SHIFT;
+   unsigned long start_addr = start_pfn << PAGE_SHIFT;
+   unsigned long end_addr = end_pfn << PAGE_SHIFT;
 
-   for (i = start ; i < end; i += MEMORY_INCREMENT)
+   for (i = start_addr; i < end_addr; i += MEMORY_INCREMENT)
numa_memory_lookup_table[i >> MEMORY_INCREMENT_SHIFT] = nid;
 }
 
_

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

Re: Data corruption with pktcdvd, kernel 2.6.10 (additional results)

2005-02-28 Thread Paul

Hi;

Out of curiosity, I tried using the ide-scsi driver, instead
of the default ide-cdrom driver. These attempts failed in various
ways, including an oops, which I wont try to detail, as I seem to
recall this is known not working.
From some of the error message that experiment resulted in,
and recent comments on linux-kernel about how the ide-cdrom driver
might not propogate errors, I tried again, but with 'hdparm -a0 -d0'
on the drive. This also had files ending in blocks of zeros and completely
zero files, but far fewer
Next, I tried making an ext2 fs instead of udf on the dvd+rw
disc, in addition to the -a0 -d0 hdparm settings. This made a dramatic
difference. The copy of the 2.6.10 kernel tree took around 2 minutes
from start to sync completion, vs. around 30 minutes on the udf fs.
And there was no corruption of files, as verifed by diff -r afterwards.
(all this using the pktcdvd device)
To me, this implies that write support for udf is shady,
or that it simply triggers some deeper bug. At the very least it
is grossly less efficient than ext2 for this task. Having udf
working well for this would be best, however, for portability.

Paul
[EMAIL PROTECTED]

Paul <[EMAIL PROTECTED]>, on Mon Feb 28, 2005 [10:50:22 PM] said:
>   Hi;
> 
>   I have played with the pktcdvd patch in the past, and most
> recently with the implementation in the 2.6.10 kernel, but never
> really stressed it. However, someone recently complained to me that
> it quite often resulted in corrupted files for them, so I performed
> a stress test; copy a kernel source tree to a cdrw and a dvd+rw.
> (mount /dev/pktcdvd/cdrw /cdrw -o rw,noatime)
> (cp -a /foo/2.6.10 /cdrw)
>   Well, diff -r shows many corrupt files in both cases.
> The corruption is either that the file is completely zero, or at
> some point it ends in zero data. In other words, all or part of
> the file end up as zero's.
>   Simpler tests, like copying a flat dir filled with 50meg
> of images did not turn up corruption.
>   I would have liked to compare writing to dvd+rw without
> pktcdvd, but although I could make a udf fs on the disc, mount it and
> start writing to it, the throughput was impossibly slow. (like 1meg in
> several minutes-- at best.) Using pktcdvd was much faster, but it
> seems to bog down after a while into the kernel tree copy-- and if you
> look at the drive light, it seems to be doing lots of reading and 
> then little blips of writing. 'vmstat 1' shows very little bi/bo,
> often times 0/0.
>   Can anyone suggest what might be done to find out what is
> going wrong here? I am using vanilla 2.6.10, udftools-1.0.0b-r3,
> a liteon LDW-451S dvd writer. The kernel is SMP with preempt enabled.
> The writer and the hardisc are both ATA.
>   Let me know if I can help with more information or testing.
> 
> Thanks;
> 
> Paul
> [EMAIL PROTECTED]
> 
> 
> -- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 3/3] Kdump: Export crash notes section address through sysfs

Vivek Goyal <[EMAIL PROTECTED]> wrote:
>
> o Following patch exports kexec global variable "crash_notes" to user space
>through sysfs as kernel attribute in /sys/kernel.

It breaks the x86_64 build.  A fix for that is below.

Please test kexec/kdump patches on all three architectures, both with your
config option enabled and with it disabled.  There are cross-compilers at
http://developer.osdl.org/dev/plm/cross_compile/


It also breaks the ppc build:

kernel/ksysfs.c: In function `crash_notes_show':
kernel/ksysfs.c:38: error: `crash_notes' undeclared (first use in this function)
kernel/ksysfs.c:38: error: (Each undeclared identifier is reported only once
kernel/ksysfs.c:38: error: for each function it appears in.)

but as ppc doesn't support crashdump, that is unfixable.

Why is the crashdump feature linked to CONFIG_KEXEC?  It should have its
own config option, which is dependent upon kexec.




kernel/ksysfs.c: In function `crash_notes_show':
kernel/ksysfs.c:38: error: `crash_notes' undeclared (first use in this function)
kernel/ksysfs.c:38: error: (Each undeclared identifier is reported only once
kernel/ksysfs.c:38: error: for each function it appears in.)


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

 25-akpm/arch/x86_64/kernel/crash.c |3 ---
 25-akpm/include/asm-x86_64/kexec.h |5 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff -puN 
include/asm-x86_64/kexec.h~kdump-export-crash-notes-section-address-through-x86_64-fix
 include/asm-x86_64/kexec.h
--- 
25/include/asm-x86_64/kexec.h~kdump-export-crash-notes-section-address-through-x86_64-fix
   2005-02-28 21:54:41.0 -0800
+++ 25-akpm/include/asm-x86_64/kexec.h  2005-02-28 21:55:12.0 -0800
@@ -25,4 +25,9 @@
 /* The native architecture */
 #define KEXEC_ARCH KEXEC_ARCH_X86_64
 
+#define MAX_NOTE_BYTES 1024
+typedef u32 note_buf_t[MAX_NOTE_BYTES/4];
+
+extern note_buf_t crash_notes[];
+
 #endif /* _X86_64_KEXEC_H */
diff -puN 
arch/x86_64/kernel/crash.c~kdump-export-crash-notes-section-address-through-x86_64-fix
 arch/x86_64/kernel/crash.c
--- 
25/arch/x86_64/kernel/crash.c~kdump-export-crash-notes-section-address-through-x86_64-fix
   2005-02-28 21:58:39.0 -0800
+++ 25-akpm/arch/x86_64/kernel/crash.c  2005-02-28 21:58:55.0 -0800
@@ -22,9 +22,6 @@
 #include 
 #include 
 
-#define MAX_NOTE_BYTES 1024
-typedef u32 note_buf_t[MAX_NOTE_BYTES/4];
-
 note_buf_t crash_notes[NR_CPUS];
 
 void machine_crash_shutdown(void)
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: disallow modular framebuffers

2005-02-28 Thread Jon Smirl

The on-going work to support XGL is going to change the significance
of modular framebuffers. Right now there is no real need to load
framebuffers on X86. In the future XGL is probably going to require
that the framebuffer be loaded. When XGL initially starts being
distributed people are not going to have framebuffer loaded so modular
framebuffer will let you load it on demand. From then on, in the XGL
case, if framebuffers weren't modular Redhat would have to compile all
75 of them into their distro kernel.

I don't think the framebuffer codebase has received the same level of
inspection that a lot of the other kernel code has. This is probably
because all X86 users can currently avoid loading them due to VGA
compatibility.

-- 
Jon Smirl
[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/

question about sockfd_lookup( )

2005-02-28 Thread MingJie Chang

Dear all,

I want to get socket information by the sockfd while accetping,

so I write a module to test sockfd_lookup(),

but I got some problems when I test it.

I hope someone can help me...

Thank you

following text is my code and error message
===
=== code ===

int my_socketcall(int call,unsigned long *args)  
{
   int ret,err;
   struct socket * sock;

   ret = run_org_socket_call(call,args);   //orignal sys_sockcall()
   
   if(call==SYS_ACCEPT&>=0) 
   {
  sock=sockfd_lookup(ret,);
  printk("lookup done\n");
   }
   return ret;
}


==
=== test and state ===

after inserting module, I use "ftp localhost" to test it.

And it has some error when I use "ls" or "mget"(I just try the 2 commands)

EX1: ls  :file list is printed, but it will block until ctrl + c

ftp> ls
227 Entering Passive Mode (127,0,0,1,68,186)
150 Here comes the directory listing.
-rwxr-xr-x1 00   13744 Feb 28 05:22 socktest
-rw-r--r--1 501  0   76288 Feb 27 19:05 vsftpd-1.1.0-1.i386.rpm
-rw---1 501  03778 Feb 27 19:29 vsftpd.conf
(blocking until ctrl+c)

after ctrl+c
receive aborted
waiting for remote to finish abort
226 Directory send OK.
500 Unknown command.
663 bytes received in 51 secs (0.013 Kbytes/sec)

ftp>

EX2:mget: block until ctrl + c ,and file is not got

ftp> mget *
(blocking until ctrl+c)
receive aborted
waiting for remote to finish abort
Unknown command.

ftp>
(file is not got)

==
== kernel message ==
and than I remove the module, try to ftp localhost again, 
and kernel will print some messages

Unable to handle kernel paging request at virtual address c845a089
 printing eip:
c845a089
*pde=02ab4067(01194067)
*pte=()
Oops: 
CPU:0
EIP:0819:[]Not tainted
EFLAGS: 00213296
eax: 0004   ebx: c6f18000   ecx: 0004   edx: 0004
esi: 0005   edi:    ebp: c6f19fbc   esp: c6f19f94
ds: 0821   es: 0821   ss: 0821
Process vsftpd (pid: 606, stackpage=c6f19000)<1>
Stack: 0005 bb80   c6f18000   c6f18000
   c6f18000 0004 bc58 c00ae4eb 0005 bb80 bc30 0004
    bc58 0066 0833 0833 0066 420daa02 082b
Call Trace: []

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

[PATCH] Add PCI device ID for new Mellanox HCA

2005-02-28 Thread Roland Dreier

Hi Greg,

Here's a device ID for the new HCA that Mellanox just introduced.
Please queue this up for 2.6.12.

Thanks,
  Roland


Add PCI device ID for new Mellanox "Sinai" InfiniHost III Lx HCA.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

--- linux-svn.orig/include/linux/pci_ids.h  2005-02-28 21:08:38.592176783 
-0800
+++ linux-svn/include/linux/pci_ids.h   2005-02-28 21:10:37.198431351 -0800
@@ -1992,6 +1992,7 @@
 #define PCI_DEVICE_ID_MELLANOX_TAVOR   0x5a44
 #define PCI_DEVICE_ID_MELLANOX_ARBEL_COMPAT 0x6278
 #define PCI_DEVICE_ID_MELLANOX_ARBEL   0x6282
+#define PCI_DEVICE_ID_MELLANOX_SINAI   0x5e8c
 
 #define PCI_VENDOR_ID_PDC  0x15e9
 #define PCI_DEVICE_ID_PDC_1841 0x1841
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Raid-6 hang on write.

2005-02-28 Thread Brad Campbell

Neil Brown wrote:
On Friday February 25, [EMAIL PROTECTED] wrote:
Turning on debugging in raid6main.c and md.c make it much harder to hit. So I'm assuming something
timing related.

raid6d --> md_check_recovery --> generic_make_request --> make_request --> get_active_stripe

Yes, there is a real problem here. I see if I can figure out the best
way to remedy it...
However I think you reported this problem against a non "-mm" kernel,
and the path from md_check_recovery to generic_make_requests only
exists in "-mm".
Could you please confirm if there is a problem with
2.6.11-rc4-bk4->bk10
There is (was). I have three kernels I was testing against. 2.6.11-rc4-bk4, 2.6.11-rc4-bk10 and
2.6.11-rc4-mm1. I moved onto 2.6.11-rc4-mm1 for my main debugging (inserting lots of printks and
generally doing stuff that was going to crash). I hope to reproduce the faults against the vanilla
2.6.11-rc4 kernels and I'm now testing with 2.6.11-rc5-bk2.

As per the original bug report, 2.6.11-rc4-bk(4/10) locked in []
get_active_stripe+0x224/0x260. Although unlike -mm1 I'm not sure of the sequence of events that
caused it and it's not anywhere as easy to hit. I am willing to investigate as time allows however.

Testing 2.6.11-rc5-bk2 and it of course is flatly refusing to misbehave. I'll keep beating on it for
a couple of days and after writing 3TB with 2.6.11-rc5-bk2, I'll go back to the older kernels and
try and reproduce the failure there. It *did* lockup 4 times in a row in get_active_stripe on the
older non -mm kernels.

Regards,
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch ide-dev 8/9] make ide_task_ioctl() use REQ_DRIVE_TASKFILE

2005-02-28 Thread Tejun Heo

 Oh, Bartlomiej, one more thing.
 If it isn't too much trouble, can you please set up a bk repository 
which contains the patches you've posted and whatever you're working on 
but hasn't yet made into ide-dev tree?  So that we don't have to juggle 
patches back and forth.  If you maintain your up-to-date working tree, 
I'll make my patches against that tree and if it's convinient for you, I 
can also set up an export tree you can pull from.

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

Re: ext3 bug

2005-02-28 Thread Jeffrey E. Hundstad

linux-2.6.10 has some bio problems that are fixed in the current 
linux-2.6.11 release candidates.  The bio problems wreaked havoc with 
XFS and there were people reporting EXT3 problems as well with this 
bug.  I'd recommend trying the latest release candidate and see if your 
problem vanishes.

--
jeffrey hundstad
jmerkey wrote:
jmerkey wrote:
Jean-Marc Valin wrote:
Le lundi 28 février 2005 à 08:31 -0700, jmerkey a écrit :
 

I see this problem infrequently on systems that have low memory 
conditions and
with heavy swapping.I have not seen it on 2.6.9 but I have seen 
it on 2.6.10.   

My machine has 1 GB RAM and I wasn't using much of it at that time (2GB
free on the swap), so I doubt that's the problem in my case.
Jean-Marc
 

Running the ext2 recover program seems to trigger some good bugs in 
2.6.10 with ext3 -- try it.  I was doing this
to test some disk tools and I managed to cause these errors with 
forcing ext2 recovery from an ext3 fs (which is
probably something to be expected.  The recover tools need to get 
syncrhonized -- have not tried with
mc yet.)Doesn't happen every time though.

Jeff

lde also causes some problems as well with ext3.  Just caused one on 
2.6.10.  stale or poisoned
cache blocks perhaps?

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/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] SELinux: null dereference in error path

Kyle Moffett <[EMAIL PROTECTED]> wrote:
>
> Err, isn't it "Acked-by:"??

Yes, I usually change it to Acked-by when it's obvious.

Signed-off-by:  "I worked on this patch"
Acked-by:   "Looks good"
Tested-by:  "You're kidding"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ppc64: Fix zImage wrapper incorrect size to flush_cache()

Hi !

This patch fixes a bug in the ppc64 zImage wrapper causing it to
pass an incorrect size to flush_cache() when flushing the data and
instruction caches prior to jumping to the kernel entry. This causes
crashes on firmare environment that do strict MMU mapping only of
actually allocated areas

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>


--- dingo/2.6.10-bk5/arch/ppc64/boot/main.c 2004-12-25 08:35:50.0 
+1100
+++ 2.6.10-bk5/arch/ppc64/boot/main.c   2005-02-16 17:10:49.194263268 +1100
@@ -200,7 +200,7 @@
vmlinux.addr += (unsigned long)elf64ph->p_offset;
vmlinux.size -= (unsigned long)elf64ph->p_offset;
 
-   flush_cache((void *)vmlinux.addr, vmlinux.memsize);
+   flush_cache((void *)vmlinux.addr, vmlinux.size);
 
if (a1)
printf("initrd head: 0x%lx\n\r", *((u32 *)initrd.addr));


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ppc32: uninorth-agp suspend support

Hi !

(This is for -mm, to be merged along with the aty128fb and radeonfb
related patches).

This patch adds suspend/resume support to the Apple UniNorth AGP bridge
to make sure AGP is properly disabled when the machine goes to sleep.
Without this, the r300 based laptops will fail to wakeup from sleep when
using the new experimental r300 DRI driver. It should also improve
reliablility in general with other chips.

Unfortunately, uninorth-agp is just a "sibling" of the video chip on the
PCI bus, and thus ends up beeing called either before the video chip
suspend routine, or after, depending on the HW layout or other random
things.

To make sure the device side of AGP is always disabled first and that we
never touch the device after having put it into D2 state (which can be
deadly), I also need the separate patch to radeonfb and aty128fb which
will make them disabled their own side if not already done by the bridge
driver.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>

--- linux-work.orig/drivers/char/agp/uninorth-agp.c 2005-03-01 
13:53:32.0 +1100
+++ linux-work/drivers/char/agp/uninorth-agp.c  2005-03-01 14:36:54.0 
+1100
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "agp.h"
@@ -51,6 +52,11 @@
 
 static void uninorth_cleanup(void)
 {
+   u32 tmp;
+
+   pci_read_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, );
+   if (!(tmp & UNI_N_CFG_GART_ENABLE))
+   return;
pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_INVAL);
pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
@@ -155,6 +161,56 @@
uninorth_tlbflush(NULL);
 }
 
+#ifdef CONFIG_PM
+static int agp_uninorth_suspend(struct pci_dev *pdev, u32 state)
+{
+   u32 cmd;
+   u8 agp;
+   struct pci_dev *device = NULL;
+
+   /* turn off AGP on the video chip, if it was enabled */
+   for_each_pci_dev(device) {
+   /* Don't touch the bridge yet, device first */
+   if (device == pdev)
+   continue;
+   /* Only deal with devices on the same bus here, no Mac has a P2P
+* bridge on the AGP port, and mucking around the entire PCI 
tree
+* is source of problems on some machines because of a bug in
+* some versions of pci_find_capability() when hitting a dead 
device
+*/
+   if (device->bus != pdev->bus)
+   continue;
+   agp = pci_find_capability(device, PCI_CAP_ID_AGP);
+   if (!agp)
+   continue;
+   pci_read_config_dword(device, agp + PCI_AGP_COMMAND, );
+   if (!(cmd & PCI_AGP_COMMAND_AGP))
+   continue;
+   printk("uninorth-agp: disabling AGP on device %s\n", 
pci_name(device));
+   cmd &= ~PCI_AGP_COMMAND_AGP;
+   pci_write_config_dword(device, agp + PCI_AGP_COMMAND, cmd);
+   }
+   
+   /* turn off AGP on the bridge */
+   agp = pci_find_capability(pdev, PCI_CAP_ID_AGP);
+   pci_read_config_dword(pdev, agp + PCI_AGP_COMMAND, );
+   if (cmd & PCI_AGP_COMMAND_AGP) {
+   printk("uninorth-agp: disabling AGP on bridge %s\n", 
pci_name(pdev));
+   cmd &= ~PCI_AGP_COMMAND_AGP;
+   pci_write_config_dword(pdev, agp + PCI_AGP_COMMAND, cmd);
+   }
+   /* turn off the GART */
+   uninorth_cleanup();
+
+   return 0;
+}
+
+static int agp_uninorth_resume(struct pci_dev *pdev)
+{
+   return 0;
+}
+#endif
+
 static int uninorth_create_gatt_table(void)
 {
char *table;
@@ -369,6 +425,10 @@
.id_table   = agp_uninorth_pci_table,
.probe  = agp_uninorth_probe,
.remove = agp_uninorth_remove,
+#ifdef CONFIG_PM
+   .suspend= agp_uninorth_suspend,
+   .resume = agp_uninorth_resume,
+#endif
 };
 
 static int __init agp_uninorth_init(void)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] SELinux: null dereference in error path

2005-02-28 Thread Kyle Moffett

On Feb 28, 2005, at 23:11, James Morris wrote:
On Tue, 1 Mar 2005, Alexander Nyberg wrote:
The 'bad' label will call function that unconditionally dereferences
the NULL pointer.
Found by the Coverity tool
Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
Signed-off-by: James Morris <[EMAIL PROTECTED]>
Err, isn't it "Acked-by:"??  I thought "Signed-off-by:" was only for 
when
the patch actually went through someone's tree and was forwarded by them
to somebody else:

EG:
John Doe writes a patch that fixes a NULL pointer deref, and he sends it
to Andrew Morton.  The maintainer of the driver, Jane McDonald, confirms
the fix via email to this list.  Andrew forwards it to Linus, who
includes it in his next release.  The resulting notations look like 
this:

Signed-off-by: John Doe
Acked-by: Jane McDonald
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 ide-dev 8/9] make ide_task_ioctl() use REQ_DRIVE_TASKFILE

2005-02-28 Thread Tejun Heo

Hello, Bartlomiej.
Hello, Jeff.

On Mon, Feb 28, 2005 at 05:14:55PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Monday 28 February 2005 16:24, Tejun Heo wrote:
> > Bartlomiej Zolnierkiewicz wrote:
> > > 
> > > Nope, it works just fine because REQ_DRIVE_TASK used only
> > > no-data protocol, please check task_no_data_intr().
> > > 
> > 
> >   Sorry, I missed that.  IDE really has a lot of ways to finish a 
> > command, doesn't it?  hdio.txt is gonna look ugly. :-)
> 
> Yep but it was a lot more "fun" when there were three PIO codepaths. ;-)
> 
> hdio.txt doesn't need to know about driver internals so no problem here.
> 

 I was talking about the TASKFILE ioctl IN register result.

> > > 
> > >> IMHO, this flag-to-get-result-registers thing is way too subtle.  How
> > >>about keeping old behavior by just not copying out register outputs in
> > >>ide_taskfile_ioctl() in applicable cases instead of not reading
> > >>registers when ending commands?  That is, unless there's some
> > >>noticeable performance impacts I'm not aware of.
> > > 
> > > 
> > > This would miss whole point of not _reading_ these registers (IO is slow).
> > > IMHO new flags denoting {in,out} registers should be added (to 
> > > 
> > > to share them with libata) so new code can be sane and old flags would map
> > > on new flags when needed.
> > 
> >   Please do it.
> > 
> >   Or, let me know what you have in mind (added fields, flag names, 
> > etc...); then, I'll do it.  I think we also need to hear Jeff's opinion 
> > as things need to be added to ata.h.
> 
> I was thinking about:
> 
> * adding ATA_TFLAG_{IN,OUT}_xxx flags (there is enough free
>   place for all flags in ->flags field of struct ata_taskfile)
> * teaching flagged_taskfile() about these flags and mapping ->tf_out_flags
>   onto ATA_TFLAG_OUT_xxx (simple mapping no need to move ->tf_out_flags
>   to ide_taskfile_ioctl() etc. - no risk of breaking something)
> * moving flagged taskfile writing to ide_tf_load_discrete() helper
> * adding ide_tf_read_discrete() helper for use by ide_end_drive_cmd()
>   and mapping ->tf_in_flags onto ATA_TFLAG_IN_xxx (ditto)
> 
> If you like this plan feel free to implement it.
> I'm also open for better ideas, comments etc.

 So, how do you like the following set of TFLAG's?

/* struct ata_taskfile flags */

/* The following six flags are used by IDE driver to control register IO. */
ATA_TFLAG_OUT_LBA48 = (1 <<  0), /* enable 48-bit LBA and HOB out */
ATA_TFLAG_OUT_ADDR  = (1 <<  1), /* enable out to nsect/lba regs */
ATA_TFLAG_OUT_DEVICE= (1 <<  2), /* enable out to device reg */
ATA_TFLAG_IN_LBA48  = (1 <<  3), /* enable 48-bit LBA and HOB in */
ATA_TFLAG_IN_ADDR   = (1 <<  4), /* enable in from nsect/lba regs */
ATA_TFLAG_IN_DEVICE = (1 <<  5), /* enable in from device reg */

/* These three aggregate flags are used by libata, as it doesn't
   really need to optimize register INs */
ATA_TFLAG_LBA48 = (ATA_TFLAG_OUT_LBA48  | ATA_TFLAG_IN_LBA48),
ATA_TFLAG_ISADDR= (ATA_TFLAG_OUT_ADDR   | ATA_TFLAG_IN_ADDR),
ATA_TFLAG_DEVICE= (ATA_TFLAG_OUT_DEVICE | ATA_TFLAG_IN_DEVICE),

ATA_TFLAG_WRITE = (1 <<  6), /* data dir */

/* The rest of TFLAGs are only for implementing ioctl direct drive
   commands in the IDE driver.  DO NOT use in other places. */
ATA_TFLAG_IO_16BIT  = (1 << 11),

ATA_TFLAG_OUT_FEATURE   = (1 << 12),
ATA_TFLAG_OUT_NSECT = (1 << 13),
ATA_TFLAG_OUT_LBAL  = (1 << 14),
ATA_TFLAG_OUT_LBAM  = (1 << 15),
ATA_TFLAG_OUT_LBAH  = (1 << 16),
ATA_TFLAG_OUT_HOB_FEATURE   = (1 << 17),
ATA_TFLAG_OUT_HOB_NSECT = (1 << 18),
ATA_TFLAG_OUT_HOB_LBAL  = (1 << 19),
ATA_TFLAG_OUT_HOB_LBAM  = (1 << 20),
ATA_TFLAG_OUT_HOB_LBAH  = (1 << 21),

ATA_TFLAG_IN_FEATURE= (1 << 22),
ATA_TFLAG_IN_NSECT  = (1 << 23),
ATA_TFLAG_IN_LBAL   = (1 << 24),
ATA_TFLAG_IN_LBAM   = (1 << 25),
ATA_TFLAG_IN_LBAH   = (1 << 26),
ATA_TFLAG_IN_HOB_FEATURE= (1 << 27),
ATA_TFLAG_IN_HOB_NSECT  = (1 << 28),
ATA_TFLAG_IN_HOB_LBAL   = (1 << 29),
ATA_TFLAG_IN_HOB_LBAM   = (1 << 30),
ATA_TFLAG_IN_HOB_LBAH   = (1 << 31),

ATA_TFLAG_OUT_MASK  = 0x007ff000,
ATA_TFLAG_IN_MASK   = 0xffc0,
ATA_TFLAG_OUT_IN_MASK   = (ATA_TFLAG_OUT_MASK | ATA_TFLAG_IN_MASK),


 ATA_TFLAG_{OUT|IN}_{LBA48|ADDR|DEVICE} should provide enough
granuality for fs/internal requests without much hassle, and
individual IO/OUT flags will only be used to implement ioctls in
separate IN/OUT functions, something like ide_{load|read}_ioctl_task().

 Would using more specific prefix for ioctl flags - like
ATA_TFLAG_IOC_{IN|OUT}_* - be better?

 libata will work as it works currently, but if optimizing out
register INs can help, converting to use IN/OUT flags

[PATCH] aty128fb: Disable AGP on suspend

Hi !

(for -mm only for now, need feedback from x86 users)

This patch improves reliability of suspend/resume by making sure AGP is
disabled on the Rage 128 chip before putting it into a suspend state. It
works in conjunction with the uninorth-agp suspend patch, but should
be harmless on machines with a different AGP bridge.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Index: linux-work/drivers/video/aty/aty128fb.c
===
--- linux-work.orig/drivers/video/aty/aty128fb.c2005-02-13 
23:18:52.0 +1100
+++ linux-work/drivers/video/aty/aty128fb.c 2005-03-01 15:17:21.0 
+1100
@@ -2334,6 +2334,7 @@
 {
struct fb_info *info = pci_get_drvdata(pdev);
struct aty128fb_par *par = info->par;
+   u8 agp;
 
/* We don't do anything but D2, for now we return 0, but
 * we may want to change that. How do we know if the BIOS
@@ -2371,6 +2372,27 @@
par->asleep = 1;
par->lock_blank = 1;
 
+   /* Disable AGP. The AGP host should have done it, but since ordering
+* isn't always properly guaranteed in this specific case, let's make
+* sure it's disabled on card side now. Ultimately, when merging fbdev
+* and dri into some common infrastructure, this will be handled
+* more nicely. The host bridge side will (or will not) be dealt with
+* by the bridge AGP driver, we don't attempt to touch it here.
+*/
+   agp = pci_find_capability(pdev, PCI_CAP_ID_AGP);
+   if (agp) {
+   u32 cmd;
+
+   pci_read_config_dword(pdev, agp + PCI_AGP_COMMAND, );
+   if (cmd & PCI_AGP_COMMAND_AGP) {
+   printk(KERN_INFO "aty128fb: AGP was enabled, "
+  "disabling ...\n");
+   cmd &= ~PCI_AGP_COMMAND_AGP;
+   pci_write_config_dword(pdev, agp + PCI_AGP_COMMAND,
+  cmd);
+   }
+   }
+
/* We need a way to make sure the fbdev layer will _not_ touch the
 * framebuffer before we put the chip to suspend state. On 2.4, I
 * used dummy fb ops, 2.5 need proper support for this at the


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] radeonfb: Disable AGP on suspend

Hi !

(for -mm only for now, need feedback from x86 users)

This patch improves reliability of suspend/resume by making sure AGP is
disabled on the radeon chip before putting it into a suspend state. It
works in conjunction with the uninorth-agp suspend patch, but should
be harmless on machines with a different AGP bridge.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Index: linux-work/drivers/video/aty/radeon_pm.c
===
--- linux-work.orig/drivers/video/aty/radeon_pm.c   2005-03-01 
14:37:10.0 +1100
+++ linux-work/drivers/video/aty/radeon_pm.c2005-03-01 14:58:44.0 
+1100
@@ -2400,7 +2400,8 @@
 * including PCI config registers, clocks, AGP conf, ...)
 */
if (suspend) {
-   printk(KERN_DEBUG "radeonfb: switching to D2 state...\n");
+   printk(KERN_DEBUG "radeonfb (%s): switching to D2 state...\n",
+  pci_name(rinfo->pdev));
 
/* Disable dynamic power management of clocks for the
 * duration of the suspend/resume process
@@ -2453,7 +2454,8 @@
mdelay(500);
}
} else {
-   printk(KERN_DEBUG "radeonfb: switching to D0 state...\n");
+   printk(KERN_DEBUG "radeonfb (%s): switching to D0 state...\n",
+  pci_name(rinfo->pdev));
 
/* Switch back PCI powermanagment to D0 */
mdelay(200);
@@ -2507,6 +2509,7 @@
 {
 struct fb_info *info = pci_get_drvdata(pdev);
 struct radeonfb_info *rinfo = info->par;
+   u8 agp;
int i;
 
if (state == pdev->dev.power.power_state)
@@ -2523,7 +2526,8 @@
if (state != PM_SUSPEND_MEM)
goto done;
if (susdisking) {
-   printk("suspending to disk but state = %d\n", state);
+   printk("radeonfb (%s): suspending to disk but state = %d\n",
+  pci_name(pdev), state);
goto done;
}
 
@@ -2546,6 +2550,28 @@
rinfo->lock_blank = 1;
del_timer_sync(>lvds_timer);
 
+   /* Disable AGP. The AGP host should have done it, but since ordering
+* isn't always properly guaranteed in this specific case, let's make
+* sure it's disabled on card side now. Ultimately, when merging fbdev
+* and dri into some common infrastructure, this will be handled
+* more nicely. The host bridge side will (or will not) be dealt with
+* by the bridge AGP driver, we don't attempt to touch it here.
+*/
+   agp = pci_find_capability(pdev, PCI_CAP_ID_AGP);
+   if (agp) {
+   u32 cmd;
+
+   pci_read_config_dword(pdev, agp + PCI_AGP_COMMAND, );
+   if (cmd & PCI_AGP_COMMAND_AGP) {
+   printk(KERN_INFO "radeonfb (%s): AGP was enabled, "
+  "disabling ...\n",
+  pci_name(pdev));
+   cmd &= ~PCI_AGP_COMMAND_AGP;
+   pci_write_config_dword(pdev, agp + PCI_AGP_COMMAND,
+  cmd);
+   }
+   }
+
/* If we support wakeup from poweroff, we save all regs we can 
including cfg
 * space
 */
@@ -2569,12 +2595,11 @@
OUTREG(LVDS_PLL_CNTL, (INREG(LVDS_PLL_CNTL) & ~3) | 
0x2);
mdelay(20);
OUTREG(LVDS_GEN_CNTL, INREG(LVDS_GEN_CNTL) & 
~(LVDS_DIGON));
-
-   // FIXME: Use PCI layer
-   for (i = 0; i < 64; ++i)
-   pci_read_config_dword(rinfo->pdev, i * 4,
- >cfg_save[i]);
}
+   // FIXME: Use PCI layer
+   for (i = 0; i < 64; ++i)
+   pci_read_config_dword(pdev, i * 4, >cfg_save[i]);
+   pci_disable_device(pdev);
}
/* If we support D2, we go to it (should be fixed later with a flag 
forcing
 * D3 only for some laptops)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] SELinux: Leak in error path

2005-02-28 Thread James Morris

On Tue, 1 Mar 2005, Alexander Nyberg wrote:

> There's a leak here in the first error path.
> 
> Found by the Coverity tool.
> 
> Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>

Signed-off-by: James Morris <[EMAIL PROTECTED]>

-- 
James Morris
<[EMAIL PROTECTED]>


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

Re: [PATCH] SELinux: null dereference in error path

2005-02-28 Thread James Morris

On Tue, 1 Mar 2005, Alexander Nyberg wrote:

> The 'bad' label will call function that unconditionally dereferences
> the NULL pointer.
> 
> Found by the Coverity tool
> 
> Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>

Signed-off-by: James Morris <[EMAIL PROTECTED]>


-- 
James Morris
<[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: ext3 bug

2005-02-28 Thread jmerkey

jmerkey wrote:
Jean-Marc Valin wrote:
Le lundi 28 février 2005 à 08:31 -0700, jmerkey a écrit :
 

I see this problem infrequently on systems that have low memory 
conditions and
with heavy swapping.I have not seen it on 2.6.9 but I have seen 
it on 2.6.10.   

My machine has 1 GB RAM and I wasn't using much of it at that time (2GB
free on the swap), so I doubt that's the problem in my case.
Jean-Marc
 

Running the ext2 recover program seems to trigger some good bugs in 
2.6.10 with ext3 -- try it.  I was doing this
to test some disk tools and I managed to cause these errors with 
forcing ext2 recovery from an ext3 fs (which is
probably something to be expected.  The recover tools need to get 
syncrhonized -- have not tried with
mc yet.)Doesn't happen every time though.

Jeff

lde also causes some problems as well with ext3.  Just caused one on 
2.6.10.  stale or poisoned
cache blocks perhaps?

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: ext3 bug

2005-02-28 Thread jmerkey

Jean-Marc Valin wrote:
Le lundi 28 février 2005 à 08:31 -0700, jmerkey a écrit :
 

I see this problem infrequently on systems that have low memory 
conditions and
with heavy swapping.I have not seen it on 2.6.9 but I have seen it 
on 2.6.10. 
   

My machine has 1 GB RAM and I wasn't using much of it at that time (2GB
free on the swap), so I doubt that's the problem in my case.
Jean-Marc
 

Running the ext2 recover program seems to trigger some good bugs in 
2.6.10 with ext3 -- try it.  I was doing this
to test some disk tools and I managed to cause these errors with forcing 
ext2 recovery from an ext3 fs (which is
probably something to be expected.  The recover tools need to get 
syncrhonized -- have not tried with
mc yet.)Doesn't happen every time though.

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: [PATCH] 2/2 Prezeroing large blocks of pages during allocation

2005-02-28 Thread Christoph Lameter

On Sun, 27 Feb 2005, Mel Gorman wrote:

> The patch also counts how many blocks of each order were zeroed. This gives
> a rough indicator if large blocks are frequently zeroed or not.  I found
> that order-0 are the most frequent zeroed block because of the per-cpu
> caches. This means we rarely win with zeroing in the allocator but the
> accounting mechanisms are still handy for the scrubber daemon.

Thanks for your efforts in integrating zeroing into your patches to reduce
fragmentation. It is true that you do not win with zeroing pages in the
allocator. However, you may avoid additional zeroing by zeroing higher
order pages and then breaking them into lower order pages (but this will
then lead to additional fragmentation).

> This patch seriously regresses how well fragmentation is handled making it
> perform almost as badly as the standard allocator. It is because the fallback
> ordering for USERZERO has a tendency to clobber the reserved lists because
> of the mix of allocation types that need to be zeroed.

Having pages of multiple orders in zeroed and not zeroed state invariably
leads to more fragmentation. I have also observed that with my patches
under many configurations. Seems that the only solution is to
intentionally either zero all free pages (which means you can coalesce
them all but you are zeroing lots of pages that did not need zeroing
after all) or you disregard the zeroed state during coalescing, either
insure that  both are zeroed or mark the results as unzeroed... both
solutions introduce additional overhead.

My favorite solution has been so far to try to zero all
pages from the  highest order downward but only when the system is idle
(or there is some hardware that does zeroing for us). And maybe we better
drop the zeroed status if a zeroed and an unzeroed page can be coalesced
to a higher order page? However, there will still be lots of unnecessary
zeroing.

Since most of the request for zeroed pages are order-0 requests, we could
do a similar thing to that M$ Windows does
(http://www.windowsitpro.com/Articles/Index.cfm?ArticleID=3774=2): Keep
a list of zeroed order 0 pages around, only put things on that list if
the system is truly idle and pick pages up for order 0 zeroed accesses.

These zero lists would needed to be managed more like cpu hotlists and
not like we do currently as buddy allocator freelists.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: disallow modular framebuffers

2005-02-28 Thread Jeff Garzik

Adrian Bunk wrote:
Hi,
while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and 
FB_SAVAGE_ACCEL=m are currently broken) I asked myself:

Do modular framebuffers really make sense?
OK, distributions like to make everything modular, but all the 
framebuffer drivers I've looked at parse driver specific options in 
their *_setup function only in the non-modular case.

And most framebuffer drivers contain a module_exit function.
Is there really any case where this is both reasonable and working?

It depends on the driver's level of hardware support, and the likely 
configuration of the hardware at boot time.

It is a case-by-case basis.
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: user space program from keyboard driver

2005-02-28 Thread Payasam Manohar

Thanks.My work is not writing keystroke logger, I know about it, but I 
want to call some other program which will run in bash ,and get some data 
from user mode and return to kernel mode on demand,
which can be called from keyboard driver.



  Thanks,
  P.Manohar,
On Mon, 28 Feb 2005, Lee Revell wrote:
On Mon, 2005-02-28 at 21:24 +0530, Payasam Manohar wrote:
hai all,
I am a newbie to kernel, I want to work on linux kernel modules.
My task is to call a user program from keyboard driver under certain
conditions. I know that we can call user program using
call_usermodehelper(), but we can not call it direcly from driver as it is
a interrupt context. So we need to call using schedule_work(). But I need
more clarification on these points. How to call user program from the
keyboard driver. Please give ur ideas for doing this.
Are you just trying to write a keystroke logger?
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ALPS touchpad not seen by 2.6.11 kernels

2005-02-28 Thread Johan Braennlund

After applying your patch, I can confirm that the kernel detects the
touchpad without the i8042.noacpi option. Thanks!

- Johan




__ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] drivers/scsi/sym53c8xx_2/sym_hipd.c: make a function static

2005-02-28 Thread Matthew Wilcox

On Mon, Feb 28, 2005 at 11:01:55PM +0100, Adrian Bunk wrote:
> This patch makes a needlessly global function static.

Thanks, committed

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

RFC: disallow modular framebuffers

Hi,

while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and 
FB_SAVAGE_ACCEL=m are currently broken) I asked myself:

Do modular framebuffers really make sense?

OK, distributions like to make everything modular, but all the 
framebuffer drivers I've looked at parse driver specific options in 
their *_setup function only in the non-modular case.

And most framebuffer drivers contain a module_exit function.
Is there really any case where this is both reasonable and working?

cu
Adrian

-- 

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

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

Re: Complicated networking problem

2005-02-28 Thread Dmitry Torokhov

On Monday 28 February 2005 21:02, [EMAIL PROTECTED] wrote:
> On Mon, 28 Feb 2005 14:59:31 +1000, Jarne Cook said:
> 
> > They are both using dhcp to the same simple network.  That's right.  Same 
> > network.  They both end up with gateway=192.168.0.1, netmask=255.255.255.0. 
> >  
> > But ofcourse they do not have the same IP addresses.
> 
> I don't suppose your network people would be willing to change it thusly:
> 
> wired ports:  gateway 192.168.0.1, netmask 255.255.255.128.0
> wireless: gateway 192.168.128.1, netmask 255.255.255.128.0
> 
> Or move the wireless up to 192.168.1.1 if they think that would confuse things
> too much.
> 
> There's a limit to how far we should bend over backwards to support stupid
> networking decisions. 192.168 *is* a /16, might as well use it. ;)
> 
> If they won't, you're pretty much stuck with binding applications to one
> interface or another.
> 

If the goal is to primarily use wired link and seamlessly swith to wireless
then look into bonding driver in failover mode with wired interface as 
primary. This way you have only one address and userspace does not notice
anything.
 
-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Complicated networking problem

2005-02-28 Thread Valdis . Kletnieks

On Mon, 28 Feb 2005 14:59:31 +1000, Jarne Cook said:

> They are both using dhcp to the same simple network.  That's right.  Same 
> network.  They both end up with gateway=192.168.0.1, netmask=255.255.255.0.  
> But ofcourse they do not have the same IP addresses.

I don't suppose your network people would be willing to change it thusly:

wired ports:  gateway 192.168.0.1, netmask 255.255.255.128.0
wireless: gateway 192.168.128.1, netmask 255.255.255.128.0

Or move the wireless up to 192.168.1.1 if they think that would confuse things
too much.

There's a limit to how far we should bend over backwards to support stupid
networking decisions. 192.168 *is* a /16, might as well use it. ;)

If they won't, you're pretty much stuck with binding applications to one
interface or another.


pgpNH8iE7xgtM.pgp
Description: PGP signature

Re: updating mtime for char/block devices?

2005-02-28 Thread Valdis . Kletnieks

On Tue, 01 Mar 2005 01:45:47 +0100, Carl-Daniel Hailfinger said:

> Sorry for not specifying my real problem which is preventing disk access
> when my laptop is running on battery.
> 
> Can I prevent mtime updates for all device files? Mounting /dev readonly
> would certainly help, but for that to work I'd have to move /dev to a
> different filesystem, right?

Or do what Fedora Core 3 does and use 'udev' to manage a /dev on a tmpfs file 
system.


pgpREYcGAexh0.pgp
Description: PGP signature

2.6.11-rc5: Promise SATA150 TX4 failure

2005-02-28 Thread Joerg Sommrey

Hi all,

a problem that was introduced between 2.6.10-ac9 and 2.6.10-ac11 made
it's way into 2.6.11-rc5.  While taking a backup onto a SCSI-streamer one
of my RAID1-arrays gets corrupted.  Afterwards the system hangs and
isn't even bootable.  Need to raidhotadd the failed partition in single
user mode to get the box working again. Error messages:

Mar  1 01:46:15 bear kernel: ata2: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:15 bear kernel: ata2: called with no error (51)!
Mar  1 01:46:15 bear kernel: ata2: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:15 bear kernel: ata2: called with no error (51)!
Mar  1 01:46:15 bear kernel: ata2: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:15 bear kernel: ata2: called with no error (51)!
Mar  1 01:46:15 bear kernel: ata2: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:15 bear kernel: ata2: called with no error (51)!
Mar  1 01:46:15 bear kernel: ata2: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:15 bear kernel: ata2: called with no error (51)!
Mar  1 01:46:15 bear kernel: SCSI error : <2 0 0 0> return code = 0x802
Mar  1 01:46:15 bear kernel: sdc: Current: sense key: Medium Error
Mar  1 01:46:15 bear kernel: Additional sense: Unrecovered read error - auto
reallocate failed
Mar  1 01:46:15 bear kernel: end_request: I/O error, dev sdc, sector 52694606
Mar  1 01:46:15 bear kernel: raid1: Disk failure on sdc2, disabling device.
Mar  1 01:46:15 bear kernel: ^IOperation continuing on 1 devices
Mar  1 01:46:15 bear kernel: raid1: sdc2: rescheduling sector 12499976
Mar  1 01:46:16 bear kernel: ata2: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:16 bear kernel: ata2: called with no error (51)!
Mar  1 01:46:16 bear kernel: SCSI error : <2 0 0 0> return code = 0x802
Mar  1 01:46:16 bear kernel: sdc: Current: sense key: Medium Error
Mar  1 01:46:16 bear kernel: Additional sense: Unrecovered read error - auto
reallocate failed
Mar  1 01:46:16 bear kernel: end_request: I/O error, dev sdc, sector 52694614
Mar  1 01:46:16 bear kernel: ata2: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:16 bear kernel: ata2: called with no error (51)!
Mar  1 01:46:16 bear kernel: SCSI error : <2 0 0 0> return code = 0x802
Mar  1 01:46:16 bear kernel: sdc: Current: sense key: Medium Error
Mar  1 01:46:16 bear kernel: Additional sense: Unrecovered read error - auto
reallocate failed
Mar  1 01:46:16 bear kernel: end_request: I/O error, dev sdc, sector 52694622
Mar  1 01:46:16 bear kernel: raid1: sdc2: rescheduling sector 12499984
Mar  1 01:46:16 bear kernel: ata2: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:16 bear kernel: ata2: called with no error (51)!
Mar  1 01:46:16 bear kernel: SCSI error : <2 0 0 0> return code = 0x802
Mar  1 01:46:16 bear kernel: sdc: Current: sense key: Medium Error
Mar  1 01:46:16 bear kernel: Additional sense: Unrecovered read error - auto
reallocate failed
Mar  1 01:46:16 bear kernel: end_request: I/O error, dev sdc, sector 52694630
Mar  1 01:46:16 bear kernel: raid1: sdc2: rescheduling sector 1250
Mar  1 01:46:16 bear kernel: RAID1 conf printout:
Mar  1 01:46:16 bear kernel:  --- wd:1 rd:2
Mar  1 01:46:16 bear kernel:  disk 0, wo:0, o:1, dev:sdb2
Mar  1 01:46:16 bear kernel:  disk 1, wo:1, o:0, dev:sdc2
Mar  1 01:46:16 bear kernel: RAID1 conf printout:
Mar  1 01:46:16 bear kernel:  --- wd:1 rd:2
Mar  1 01:46:16 bear kernel:  disk 0, wo:0, o:1, dev:sdb2
Mar  1 01:46:16 bear kernel: raid1: sdb2: redirecting sector 12499976 to another
mirror
Mar  1 01:46:16 bear kernel: raid1: sdb2: redirecting sector 12499984 to another
mirror
Mar  1 01:46:16 bear kernel: raid1: sdb2: redirecting sector 1250 to another
mirror
Mar  1 01:46:16 bear kernel: ata1: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:16 bear kernel: ata1: called with no error (51)!
Mar  1 01:46:16 bear kernel: ata1: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:16 bear kernel: ata1: called with no error (51)!
Mar  1 01:46:16 bear kernel: ata1: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:16 bear kernel: ata1: called with no error (51)!
Mar  1 01:46:16 bear kernel: ata1: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:16 bear kernel: ata1: called with no error (51)!
Mar  1 01:46:16 bear kernel: ata1: status=0x51 { DriveReady SeekComplete Error }
Mar  1 01:46:16 bear kernel: ata1: called with no error (51)!
Mar  1 01:46:16 bear kernel: SCSI error : <1 0 0 0> return code = 0x802
Mar  1 01:46:16 bear kernel: sdb: Current: sense key: Medium Error

etc. until hard reboot.

The failing array consists of two partitions of two SATA disks connected
to a Promise SATA150 TX4 controller.

-jo

-- 
-rw-r--r--  1 jo users 63 2005-03-01 02:26 /home/jo/.signature
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Re: [andrea@cpushare.com: Re: [Twisted-Python] linux kernel 2.6.11-rc broke twisted process pipes]

2005-02-28 Thread Andrea Arcangeli

On Mon, Feb 28, 2005 at 05:16:35PM -0800, Linus Torvalds wrote:
> I assume you mean 2.6.11-rc5, not 2.6.5-rc11.

Indeed sorry, I've probably typed that 2.6.5 number too many times ;)

> As you say, for pipes, none. It only matters on sockets that can have
> urgent data (aka oob - out-of-band data).

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

Re: swapper: page allocation failure. order:1, mode:0x20

Nigel Cunningham wrote:
Hi.
On Tue, 2005-03-01 at 12:10, Robert Hancock wrote:
Bernd Schubert wrote:
Essentially the tg3 Ethernet driver is trying to allocate memory to 
store a received packet, and is unable to do so. Since this is done 
inside interrupt context, this allocation has to be serviced from 
physical memory. Order 1 means it only wanted one page of memory, and 

Minor point, I know, but it's 2 pages of memory. If it couldn't get an
order zero page, that would be even greater hernia material!
Indeed.. off-by-one error :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swapper: page allocation failure. order:1, mode:0x20

2005-02-28 Thread Nick Piggin

Robert Hancock wrote:
Bernd Schubert wrote:
Oh no, not this page allocation problems again. In summer I already 
posted problems with page allocation errors with 2.6.7, but to me it 
seemed that nobody cared. That time we got those problems every 
morning during the cron jobs and our main file server always 
completely crashed.
This time its our cluster master system and first happend after an 
uptime of 89 days, kernel is 2.6.9. Besides of those messages, the 
system still seems to run stable

I really beg for help here, so please please please help me solving 
this probem. What can I do to solve it?

You should upgrade to the newest kernel if possible. If that's not possible,
increase /proc/sys/vm/min_free_kbytes
This allocation failure really should not cause your system to crash, but
increasing min_free_kbytes will make it less likely that you will see an
allocation failure.
First a (dumb) question, what does 'page allocation failure' really 
mean? Is it some out of memory case?
Feb 28 10:04:45 hitchcock kernel: swapper: page allocation failure. 
order:1, mode:0x20
Feb 28 10:04:45 hitchcock kernel:
Feb 28 10:04:45 hitchcock kernel: Call Trace: 
{__alloc_pages+878} 
{__get_free_pages+14}
Feb 28 10:04:45 hitchcock kernel:
{kmem_getpages+38} 
{ip_frag_create+26}
Feb 28 10:04:45 hitchcock kernel:
{cache_grow+190} 
{cache_alloc_refill+560}
Feb 28 10:04:45 hitchcock kernel:
{__kmalloc+195} {alloc_skb+64}
Feb 28 10:04:45 hitchcock kernel:
{tg3_alloc_rx_skb+222} {tg3_rx+371}
Feb 28 10:04:45 hitchcock kernel:
{tg3_poll+183} {net_rx_action+134}

Essentially the tg3 Ethernet driver is trying to allocate memory to 
store a received packet, and is unable to do so. Since this is done 
inside interrupt context, this allocation has to be serviced from 
physical memory. Order 1 means it only wanted one page of memory, and 
since that failed it looks like the system must have been awfully 
short on available physical RAM.. it could be some kind of kernel 
memory leak or VM issue, though this condition may not be entirely 
unexpected in certain cases, like if the system has little physical 
RAM free at a certain point and then a flood of network packets arrive.

Yep. The reason why these failures are beeing seen is that earlier 
kernels did
not reserve enough memory for GFP_ATOMIC allocations. Later kernels 
increased
this, and also made higher order (ie. greater than 0) GFP_ATOMIC allocations
more robust.


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

Re: Complicated networking problem

Jarne Cook wrote:
Is there a way to allow an application which has bound to wlan0 
(192.168.0.202) and an application bound to eth0 (192.168.0.238) both have 
access to the internet at the same time, and not require an application to 
bind to a different local address?
I'm not sure exactly what you want to have happen here.. if an 
application is making outbound connections it has to effectively use one 
interface or the other. If you want to switch between the two of them 
automatically, something like 
NetworkManager(http://people.redhat.com/dcbw/NetworkManager/) may work, 
however it's not going to be seamless (as in, preserving open 
connections), since the IP addresses are different..

--
Robert Hancock  Saskatoon, SK, Canada
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swapper: page allocation failure. order:1, mode:0x20

2005-02-28 Thread Nigel Cunningham

Hi.

On Tue, 2005-03-01 at 12:10, Robert Hancock wrote:
> Bernd Schubert wrote:
> Essentially the tg3 Ethernet driver is trying to allocate memory to 
> store a received packet, and is unable to do so. Since this is done 
> inside interrupt context, this allocation has to be serviced from 
> physical memory. Order 1 means it only wanted one page of memory, and 

Minor point, I know, but it's 2 pages of memory. If it couldn't get an
order zero page, that would be even greater hernia material!

Regards,

Nigel

> since that failed it looks like the system must have been awfully short 
> on available physical RAM.. it could be some kind of kernel memory leak 
> or VM issue, though this condition may not be entirely unexpected in 
> certain cases, like if the system has little physical RAM free at a 
> certain point and then a flood of network packets arrive.
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de


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

Re: [PATCH] nfs client O_DIRECT oops

2005-02-28 Thread Linus Torvalds

On Mon, 28 Feb 2005, Pete Zaitcev wrote:
> 
> This is how I think it should have been fixed:

Since this seems a cleanup, I'll drop it for now. Can you re-send after 
2.6.11 (or forward it to the nfs people) so that it gets cleaned up at 
some point? I do agree that your patch seems to be cleaner.

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

[2.6 patch] drivers/serial/8250.c: make a variable static

This patch makes a needlessly global variable static.

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

--- linux-2.6.11-rc4-mm1-full/drivers/serial/8250.c.old 2005-02-28 
23:03:34.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/serial/8250.c 2005-02-28 
23:06:55.0 +0100
@@ -51,7 +51,7 @@
  *   share_irqs - whether we pass SA_SHIRQ to request_irq().  This option
  *is unsafe when used on edge-triggered interrupts.
  */
-unsigned int share_irqs = SERIAL8250_SHARE_IRQS;
+static unsigned int share_irqs = SERIAL8250_SHARE_IRQS;
 
 /*
  * Debugging.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [andrea@cpushare.com: Re: [Twisted-Python] linux kernel 2.6.11-rc broke twisted process pipes]

2005-02-28 Thread Linus Torvalds



On Tue, 1 Mar 2005, Andrea Arcangeli wrote:
> 
> I tend to agree that previously it was working by luck, and I suspect
> it's still working by luck in openbsd too, since openbsd seem to do very
> similar to what linux was doing in 2.6.5-rc11 (and 2.6.5-rc11 made a lot
> more sense than 2.6.9 and previous)

I assume you mean 2.6.11-rc5, not 2.6.5-rc11.

> http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html
> 
> POLLIN
>  Data other than high-priority data may be read without blocking. [..]
> POLLRDNORM
>  Normal data (priority band equals 0) may be read without blocking. [..]
> 
> btw, I don't really know the difference of POLLIN and POLLRDNORM

As you say, for pipes, none. It only matters on sockets that can have
urgent data (aka oob - out-of-band data).

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

Re: swapper: page allocation failure. order:1, mode:0x20

Bernd Schubert wrote:
Oh no, not this page allocation problems again. In summer I already posted 
problems with page allocation errors with 2.6.7, but to me it seemed that 
nobody cared. That time we got those problems every morning during the cron 
jobs and our main file server always completely crashed.
This time its our cluster master system and first happend after an uptime 
of 89 days, kernel is 2.6.9. Besides of those messages, the system still 
seems to run stable

I really beg for help here, so please please please help me solving this 
probem. What can I do to solve it?

First a (dumb) question, what does 'page allocation failure' really mean? 
Is it some out of memory case?
Feb 28 10:04:45 hitchcock kernel: swapper: page allocation failure. order:1, mode:0x20
Feb 28 10:04:45 hitchcock kernel:
Feb 28 10:04:45 hitchcock kernel: Call Trace: {__alloc_pages+878} {__get_free_pages+14}
Feb 28 10:04:45 hitchcock kernel:{kmem_getpages+38} {ip_frag_create+26}
Feb 28 10:04:45 hitchcock kernel:{cache_grow+190} {cache_alloc_refill+560}
Feb 28 10:04:45 hitchcock kernel:{__kmalloc+195} {alloc_skb+64}
Feb 28 10:04:45 hitchcock kernel:{tg3_alloc_rx_skb+222} {tg3_rx+371}
Feb 28 10:04:45 hitchcock kernel:{tg3_poll+183} {net_rx_action+134}
Essentially the tg3 Ethernet driver is trying to allocate memory to 
store a received packet, and is unable to do so. Since this is done 
inside interrupt context, this allocation has to be serviced from 
physical memory. Order 1 means it only wanted one page of memory, and 
since that failed it looks like the system must have been awfully short 
on available physical RAM.. it could be some kind of kernel memory leak 
or VM issue, though this condition may not be entirely unexpected in 
certain cases, like if the system has little physical RAM free at a 
certain point and then a flood of network packets arrive.

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[andrea@cpushare.com: Re: [Twisted-Python] linux kernel 2.6.11-rc broke twisted process pipes]

2005-02-28 Thread Andrea Arcangeli

Just a short update since I got feedback on the twisted side. The "r and
w" check that twisted does seems really correct and in sync with current
BK: POLLERR will make both of these bitmask trigger and this should lead
to the "r and w" condition being True.

#define POLLIN_SET (POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP | POLLERR)
#define POLLOUT_SET (POLLWRBAND | POLLWRNORM | POLLOUT | POLLERR)

Previously "r and w" didn't mean disconnect because POLLIN was forced to
be set (or anyway it could be set in 2.6.11-rc5 if the buffer wasn't
empty).

So the select side of things matches what the twisted code think should
happen when a reader disconnects.

They also said at the end that the select call is only used with the
selectreactor, and the pollreactor should be just fine with POLLERR
being returned and POLLIN never being returned. So I think we should be
fine with it too already, but I asked to double check it just in case.
(my test however are successful with pollreactor, infact I've never
tested the selectreactor, to me it was the pollreactor breaking)

I tend to agree that previously it was working by luck, and I suspect
it's still working by luck in openbsd too, since openbsd seem to do very
similar to what linux was doing in 2.6.5-rc11 (and 2.6.5-rc11 made a lot
more sense than 2.6.9 and previous): that is to return poll information
relevant for both the reader and the writer at the same time. So the
assumption that "r and w" means "reader disconnected" may not be really
true on openbsd like it was not true for 2.6.5-rc11. I didn't check
other bsd implementations but you can find a link at the end of the
forward.

Perhaps the only thing we could change on top of the current code is to
set POLLIN|POLLRDNORM at the same time of POLLERR/POLLHUP, but that
makes no sense accoding to SUS poll specifications (they say POLLIN
means there's data to be read, and on a WRONLY fd nothing can be read),
and such a change would be a noop for select(2). So I find the current
kernel code more correct.

This is the SUS specs:

http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html

POLLIN
 Data other than high-priority data may be read without blocking. [..]
POLLRDNORM
 Normal data (priority band equals 0) may be read without blocking. [..]

btw, I don't really know the difference of POLLIN and POLLRDNORM, I
suspect there's no difference for pipe(2) that has a single band (I
guess it probably matters only for protocols with multiple bands like
TCP that can send a out of band message and have it arrive to userland
first regardless of the window size already on the wire).

- Forwarded message from Andrea Arcangeli <[EMAIL PROTECTED]> -

Date: Tue, 1 Mar 2005 01:37:23 +0100
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Reply-To: Twisted general discussion <[EMAIL PROTECTED]>
To: Twisted general discussion <[EMAIL PROTECTED]>
Subject: Re: [Twisted-Python] linux kernel 2.6.11-rc broke twisted process
pipes
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.1.4
Errors-To: [EMAIL PROTECTED]

BTW, I'm sending as [EMAIL PROTECTED] but this email is really meant
to be from [EMAIL PROTECTED], the lists are set so that I can't post unless
I'm subscribed and to avoid unnecessary email load, I'm avoiding to
subscribe two of my accounts to the same list.

On Mon, Feb 28, 2005 at 05:52:05PM -0500, James Y Knight wrote:
> I agree this code is somewhat suboptimal. However, I do not agree that 
> it works only by luck.

The thing is that readable and writeable (in select(2) terms) could be
returned from linux 2.6.9 and all previous kernels immediatly without
sleeping, even if there was no disconnect event. You only needed the
write buffer empty for it to return POLLIN|POLLOUT without sleeping.
That's what I mean with "by luck". It wasn't twisted mistake but a linux
mistake apparently.

That check of "r and w" definitely could be true even if the other side
of the pipe didn't disconnect in past linux.

> In response to your main question of "why is it checking for 
> readability at all", there is a good answer: to get the disconnect 
> event without trying to write data. Select doesn't have a "err" fdset, 

Ok, btw even linux always returns the fd in both readable and writeable
when the other side of the pipe disconnects. This because we raise a
POLLERR and this is the mask to check when a fd is readable/writeable

#define POLLIN_SET (POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP | POLLERR)
#define POLLOUT_SET (POLLWRBAND | POLLWRNORM | POLLOUT | POLLERR)

So when POLLERR is raised, the fd is returned readable and writeable
from select.

Current kernel code is this:

static unsigned int
pipe_poll(struct file *filp, poll_table *wait)
{
unsigned int mask;
struct inode *inode = filp->f_dentry->d_inode;
struct pipe_inode_info *info = inode->i_pipe;
int nrbufs;

poll_wait(filp, PIPE_WAIT(*inode), wait);

/* Reading only -- no need for acquiring the semaphore.  */
nrbufs =

Re: [linux-usb-devel] [2.6 patch] drivers/usb/gadget/config.c: make a function static

2005-02-28 Thread David Brownell

On Monday 28 February 2005 4:34 pm, Adrian Bunk wrote:
> This patch makes a needlessly global function static.

You sent this before, and time hasn't improved it.  This function
is exported to support composite (multi-function) devices, which
need to assemble config descriptors in chunks (config + N* function)
instead of all-at-once (config + single function).


> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> 
>  drivers/usb/gadget/config.c |2 +-
>  include/linux/usb_gadget.h  |6 --
>  2 files changed, 1 insertion(+), 7 deletions(-)
> 
> --- linux-2.6.11-rc4-mm1-full/include/linux/usb_gadget.h.old  2005-02-28 
> 23:15:09.0 +0100
> +++ linux-2.6.11-rc4-mm1-full/include/linux/usb_gadget.h  2005-02-28 
> 23:15:24.0 +0100
> @@ -854,12 +854,6 @@
>  
>  /*-*/
>  
> -/* utility to simplify managing config descriptors */
> -
> -/* write vector of descriptors into buffer */
> -int usb_descriptor_fillbuf(void *, unsigned,
> - const struct usb_descriptor_header **);
> -
>  /* build config descriptor from single descriptor vector */
>  int usb_gadget_config_buf(const struct usb_config_descriptor *config,
>   void *buf, unsigned buflen, const struct usb_descriptor_header **desc);
> --- linux-2.6.11-rc4-mm1-full/drivers/usb/gadget/config.c.old 2005-02-28 
> 23:15:34.0 +0100
> +++ linux-2.6.11-rc4-mm1-full/drivers/usb/gadget/config.c 2005-02-28 
> 23:15:49.0 +0100
> @@ -39,7 +39,7 @@
>   * as part of configuring a composite device; or in other cases where
>   * sets of descriptors need to be marshaled.
>   */
> -int
> +static int
>  usb_descriptor_fillbuf(void *buf, unsigned buflen,
>   const struct usb_descriptor_header **src)
>  {
> 
> 
> 
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] nfs client O_DIRECT oops

2005-02-28 Thread Pete Zaitcev

On Mon, 28 Feb 2005 14:02:30 -0500, Steve Dickson <[EMAIL PROTECTED]> wrote:

> Discovered using AKPM's ext3-tools: odwrite -ko 0 16385 foo

> Signed-off-by: Bill Rugolsky <[EMAIL PROTECTED]>
> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

The root cause of the bug is that the code violates the principle of the
least surprise, which in this case is: if a function fails, you do not have
to clean up for that function. Therefore, Bill's fix papers over instead
of fixing.

This is how I think it should have been fixed:

--- linux-2.6.9-5.EL/fs/nfs/direct.c2004-10-18 14:55:07.0 -0700
+++ linux-2.6.9-5.EL-nfs/fs/nfs/direct.c2005-02-28 16:48:54.0 
-0800
@@ -86,6 +86,8 @@
page_count, (rw == READ), 0,
*pages, NULL);
up_read(>mm->mmap_sem);
+   if (result < 0)
+   kfree(*pages);
}
return result;
 }
@@ -211,7 +213,6 @@
 
 page_count = nfs_get_user_pages(READ, user_addr, size, );
 if (page_count < 0) {
-nfs_free_user_pages(pages, 0, 0);
if (tot_bytes > 0)
break;
 return page_count;
@@ -377,7 +378,6 @@
 
 page_count = nfs_get_user_pages(WRITE, user_addr, size, 
);
 if (page_count < 0) {
-nfs_free_user_pages(pages, 0, 0);
if (tot_bytes > 0)
break;
 return page_count;

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

Re: [PATCH 2.6.11-rc4] oom_kill.c: Kill obvious processes first

2005-02-28 Thread Parag Warudkar

One person pointed out (rightly so) that this patch might end up killing a 
Oracle process for example since it occupies more than 60% memory - which is 
not good. While that may be case for a server, I think for a desktop this patch 
is right - it allows the user to gain control on the machine which has gone OOM.

> Thank you for the patch, I'm in agreement with the idea, and I'll give 
> it a try after I look at the code a bit. The current code frequently 
> seems bit... non-deterministic.
> 
> -- 
> -bill davidsen ([EMAIL PROTECTED])
> "The secret to procrastination is to put things off until the
>   last possible moment - but no longer"  -me

I think oom_kill.c needs more intelligence and customizability. It should 
evaluate the per process rate of memory allocation for example. With that, it 
can determine if a process has had a steady VM size and give it less badness 
since there is a good possibility that some other process(es) might have gone 
bad  doing fork bombs or leaking memory. In short less badness for processes 
behaving well for a long time and not taking all the memory and not asking for 
more.

OTOH we need more configurability - Desktop settings might depict A)Dont kill X 
B) Don't kill KDE for example. Then OOM killer then can spare those processes 
to see if killing other processes is going to benefit. (If X / KDE went bad and 
gobbled up memory, may be it might still kill it - again rate of allocation 
matters.) Server admins might specify no killing of a database process until 
unless it is occupying all memory etc..

Parag

> Parag Warudkar wrote:
> > oom_kill.c misses very obvious targets - For example, a process occupying > 
> > 80% memory, not superuser and not having hardware access gets ignored by 
> > it. 
> > Logically, such a process, if killed , is going to make things return to 
> > normal thereby eliminating the need for oom killer to further scan for more 
> > processes.
> > 
> > This patch calculates the approximate integer percentage of memory occupied 
> > by 
> > the process by looking at num_physpages and p->mm->total_vm. If this 
> > process 
> > is not super user and doesn't have hardware access, and the percentage of 
> > occupied memory is more than 60%, it immediately selects this process for 
> > killing by returning unusually high points from badness().
> > 
> > Without this patch, when KDevelop running as non root user gobbles up 90% 
> > memory, the OOM killer kills many other irrelevant processes but not 
> > KDevelop 
> > And machine never recovers.. (Pls see LKML for my previous message with 
> > subject "2.6.11-rc4 OOM Killer - Kill the Innocent".) 
> > 
> > With this patch OOM killer immediately kills kdevelop and machine recovers.
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: 2.6.11-rc4 doubles CPU temperature

Ben Castricum wrote:
For some weird reason, 2.6.11-rc4 up to the current BK tree about 
doubles my
CPU temperature from 20 degrees Celcius to 40 while everything else is
unchanged (load/processes/config). The system does seem a bit more 
sluggish,
but that may just be a feeling. A cat /proc/cpu gives me

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 6
model name  : Celeron (Mendocino)
stepping: 5
cpu MHz : 475.100
How are you determining this temperature? 20 degrees seems pretty 
unlikely for any CPU, let alone a Mendocino Celeron - 40 degrees is more 
reasonable..

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

Re: updating mtime for char/block devices?

2005-02-28 Thread Carl-Daniel Hailfinger

Arjan van de Ven schrieb:
> On Mon, 2005-02-28 at 00:51 +0100, Carl-Daniel Hailfinger wrote:
> 
>>Hi,
>>
>>is it intentional that
>>echo foo >/dev/hda1
>>doesn't update the mtime of the device node, but
>>echo foo >/dev/tty10
>>does update the mtime of the device node?
>>
>>And no, mounting with the noatime flag doesn't help because the
>>mtime is updated. IIRC some time ago this behaviour was different,
>>but I could easily be mistaken.
> 
> 
> devices are tricky in general in this respect, /dev may be mounted read
> only for example ;)

Sorry for not specifying my real problem which is preventing disk access
when my laptop is running on battery.

Can I prevent mtime updates for all device files? Mounting /dev readonly
would certainly help, but for that to work I'd have to move /dev to a
different filesystem, right?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] USB: possible cleanups

Before I'm getting flamed to death:
This patch contains possible cleanups. If parts of this patch conflict
with pending changes these parts of my patch have to be dropped.

This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions:
  - core/usb.c: usb_buffer_map
  - core/usb.c: usb_buffer_unmap
- remove the following unneeded EXPORT_SYMBOL's:
  - core/hcd.c: usb_bus_init
  - core/hcd.c: usb_alloc_bus
  - core/hcd.c: usb_register_bus
  - core/hcd.c: usb_deregister_bus
  - core/hcd.c: usb_hcd_irq
  - core/usb.c: usb_buffer_map
  - core/usb.c: usb_buffer_unmap
  - core/buffer.c: hcd_buffer_create
  - core/buffer.c: hcd_buffer_destroy

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

---

 drivers/usb/core/buffer.c   |2 --
 drivers/usb/core/config.c   |2 +-
 drivers/usb/core/hcd.c  |7 +--
 drivers/usb/core/hcd.h  |1 -
 drivers/usb/core/hub.c  |3 ++-
 drivers/usb/core/message.c  |   10 ++
 drivers/usb/core/usb.c  |   14 +-
 drivers/usb/core/usb.h  |5 -
 drivers/usb/input/aiptek.c  |2 +-
 drivers/usb/media/ibmcam.c  |3 ++-
 drivers/usb/misc/sisusbvga/sisusb.c |8 
 drivers/usb/net/catc.c  |3 ++-
 drivers/usb/net/kawethfw.h  |8 
 include/linux/usb.h |4 ++--
 14 files changed, 34 insertions(+), 38 deletions(-)

--- linux-2.6.11-rc4-mm1-full/drivers/usb/core/config.c.old 2005-02-28 
23:48:53.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/core/config.c 2005-02-28 
23:49:04.0 +0100
@@ -221,7 +221,7 @@
return buffer - buffer0 + i;
 }
 
-int usb_parse_configuration(struct device *ddev, int cfgidx,
+static int usb_parse_configuration(struct device *ddev, int cfgidx,
 struct usb_host_config *config, unsigned char *buffer, int size)
 {
unsigned char *buffer0 = buffer;
--- linux-2.6.11-rc4-mm1-full/drivers/usb/core/hcd.h.old2005-02-28 
23:52:39.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/core/hcd.h2005-02-28 
23:52:44.0 +0100
@@ -208,7 +208,6 @@
 };
 
 extern void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb, struct 
pt_regs *regs);
-extern void usb_bus_init (struct usb_bus *bus);
 
 extern struct usb_hcd *usb_create_hcd (const struct hc_driver *driver,
struct device *dev, char *bus_name);
--- linux-2.6.11-rc4-mm1-full/drivers/usb/core/hcd.c.old2005-02-28 
23:51:56.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/core/hcd.c2005-03-01 
00:27:36.0 +0100
@@ -701,7 +701,7 @@
  * This code is used to initialize a usb_bus structure, memory for which is
  * separately managed.
  */
-void usb_bus_init (struct usb_bus *bus)
+static void usb_bus_init (struct usb_bus *bus)
 {
memset (>devmap, 0, sizeof(struct usb_devmap));
 
@@ -719,7 +719,6 @@
class_device_initialize(>class_dev);
bus->class_dev.class = _host_class;
 }
-EXPORT_SYMBOL (usb_bus_init);
 
 /**
  * usb_alloc_bus - creates a new USB host controller structure
@@ -745,7 +744,6 @@
bus->op = op;
return bus;
 }
-EXPORT_SYMBOL (usb_alloc_bus);
 
 /*-*/
 
@@ -792,7 +790,6 @@
dev_info (bus->controller, "new USB bus registered, assigned bus number 
%d\n", bus->busnum);
return 0;
 }
-EXPORT_SYMBOL (usb_register_bus);
 
 /**
  * usb_deregister_bus - deregisters the USB host controller
@@ -822,7 +819,6 @@
 
class_device_del(>class_dev);
 }
-EXPORT_SYMBOL (usb_deregister_bus);
 
 /**
  * usb_register_root_hub - called by HCD to register its root hub 
@@ -1557,7 +1553,6 @@
usb_hc_died (hcd);
return IRQ_HANDLED;
 }
-EXPORT_SYMBOL (usb_hcd_irq);
 
 /*-*/
 
--- linux-2.6.11-rc4-mm1-full/drivers/usb/core/hub.c.old2005-02-28 
23:55:36.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/core/hub.c2005-02-28 
23:56:41.0 +0100
@@ -1525,7 +1525,8 @@
  * Linux (2.6) currently has NO mechanisms to initiate that:  no khubd
  * timer, no SRP, no requests through sysfs.
  */
-int __usb_suspend_device (struct usb_device *udev, int port1, pm_message_t 
state)
+static int __usb_suspend_device (struct usb_device *udev, int port1,
+pm_message_t state)
 {
int status;
 
--- linux-2.6.11-rc4-mm1-full/drivers/usb/core/usb.h.old2005-02-28 
23:57:04.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/core/usb.h2005-03-01 
00:03:31.0 +0100
@@ -4,8 +4,6 @@
 extern void usb_remove_sysfs_dev_files (struct usb_device *dev);
 extern void usb_create_sysfs_intf_files (struct usb_interface *intf);
 extern void usb_remove_sysfs_intf_files (struct usb_interface

[2.6 patch] drivers/usb/net/pegasus.c: make some code static

This patch makes some needlessly global code static.

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

---

 drivers/usb/net/pegasus.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.11-rc4-mm1-full/drivers/usb/net/pegasus.c.old 2005-02-28 
23:26:58.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/net/pegasus.c 2005-02-28 
23:27:45.0 +0100
@@ -956,7 +956,8 @@
return 0;
 }
 
-void pegasus_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
+static void pegasus_get_drvinfo(struct net_device *dev,
+   struct ethtool_drvinfo *info)
 {
pegasus_t *pegasus = netdev_priv(dev);
strncpy(info->driver, driver_name, sizeof (info->driver) - 1);
@@ -1156,10 +1157,10 @@
 }
 
 
-struct workqueue_struct *pegasus_workqueue = NULL;
+static struct workqueue_struct *pegasus_workqueue = NULL;
 #define CARRIER_CHECK_DELAY (2 * HZ)
 
-void check_carrier(void *data)
+static void check_carrier(void *data)
 {
pegasus_t *pegasus = data;
set_carrier(pegasus->net);

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

Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-02-28 Thread Andrea Arcangeli

On Tue, Mar 01, 2005 at 01:32:47AM +0100, Adrian Bunk wrote:
> If you want to use Cpushare, you know that you have to enable seccomp.

Oh yeah, I know it, you know it, but not everyone will know it while
configuring the kernel, infact I doubt they'll even know what Cpushare
is about while they configure the kernel ;). And I doubt they should be
required to know all those details in order to make that choice, and my
point is that seccomp is low overhead enough that everyone can enable it
if they're unsure, just in case. I'm just trying to explain why I
recommend it to Y by default "if unsure".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] prepare x86/ppc64 DISCONTIG code for hotplug

Dave Hansen <[EMAIL PROTECTED]> wrote:
>
> Subject pretty much says it all.  Descriptions are in the individual
> patches.  These patches replace the
> "allow-hot-add-enabled-i386-numa-box-to-boot.patch" which is currently
> in -mm.  Please drop it.  
> 
> They apply to 2.6.11-rc5 after a few patches from -mm which conflicted:
> 
>   stop-using-base-argument-in-__free_pages_bulk.patch
>   consolidate-set_max_mapnr_init-implementations.patch
>   refactor-i386-memory-setup.patch
>   remove-free_all_bootmem-define.patch
>   mostly-i386-mm-cleanup.patch
> 
> Boot-tested on plain x86 laptop, NUMAQ, and Summit.  These probably
> deserve to stay in -mm for a release or two.
> 

Most of these patches needed little fixups due to other patches which you
folks have already sent me:

allow-hot-add-enabled-i386-numa-box-to-boot
refactor-i386-memory-setup
consolidate-set_max_mapnr_init-implementations

I'll try to get a -mm out this evening - please retest this stuff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] drivers/usb/serial/: make some functions static

This patch makes some needlessly global functions static.

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

---

 drivers/usb/serial/ftdi_sio.c   |   12 +++-
 drivers/usb/serial/garmin_gps.c |4 ++--
 drivers/usb/serial/ipw.c|4 ++--
 3 files changed, 11 insertions(+), 9 deletions(-)

--- linux-2.6.11-rc4-mm1-full/drivers/usb/serial/ftdi_sio.c.old 2005-02-28 
23:31:03.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/serial/ftdi_sio.c 2005-02-28 
23:32:13.0 +0100
@@ -1187,7 +1187,7 @@
  * ***
  */
 
-ssize_t show_latency_timer(struct device *dev, char *buf)
+static ssize_t show_latency_timer(struct device *dev, char *buf)
 {
struct usb_serial_port *port = to_usb_serial_port(dev);
struct ftdi_private *priv = usb_get_serial_port_data(port);
@@ -1214,7 +1214,8 @@
 }
 
 /* Write a new value of the latency timer, in units of milliseconds. */
-ssize_t store_latency_timer(struct device *dev, const char *valbuf, size_t 
count)
+static ssize_t store_latency_timer(struct device *dev, const char *valbuf,
+  size_t count)
 {
struct usb_serial_port *port = to_usb_serial_port(dev);
struct ftdi_private *priv = usb_get_serial_port_data(port);
@@ -1244,7 +1245,8 @@
 
 /* Write an event character directly to the FTDI register.  The ASCII
value is in the low 8 bits, with the enable bit in the 9th bit. */
-ssize_t store_event_char(struct device *dev, const char *valbuf, size_t count)
+static ssize_t store_event_char(struct device *dev, const char *valbuf,
+   size_t count)
 {
struct usb_serial_port *port = to_usb_serial_port(dev);
struct ftdi_private *priv = usb_get_serial_port_data(port);
@@ -1275,7 +1277,7 @@
 static DEVICE_ATTR(latency_timer, S_IWUGO | S_IRUGO, show_latency_timer, 
store_latency_timer);
 static DEVICE_ATTR(event_char, S_IWUGO, NULL, store_event_char);
 
-void create_sysfs_attrs(struct usb_serial *serial)
+static void create_sysfs_attrs(struct usb_serial *serial)
 {  
struct ftdi_private *priv;
struct usb_device *udev;
@@ -1292,7 +1294,7 @@
}
 }
 
-void remove_sysfs_attrs(struct usb_serial *serial)
+static void remove_sysfs_attrs(struct usb_serial *serial)
 {
struct ftdi_private *priv;
struct usb_device *udev;
--- linux-2.6.11-rc4-mm1-full/drivers/usb/serial/garmin_gps.c.old   
2005-02-28 23:32:28.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/serial/garmin_gps.c   2005-02-28 
23:32:50.0 +0100
@@ -614,8 +614,8 @@
  *
  * return <0 on error, 0 if packet is incomplete or > 0 if packet was sent
  */
-int gsp_send(struct garmin_data * garmin_data_p, const unsigned char *buf,
-  int count)
+static int gsp_send(struct garmin_data * garmin_data_p,
+   const unsigned char *buf, int count)
 {
const unsigned char *src;
unsigned char *dst;
--- linux-2.6.11-rc4-mm1-full/drivers/usb/serial/ipw.c.old  2005-02-28 
23:33:10.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/serial/ipw.c  2005-02-28 
23:33:43.0 +0100
@@ -457,7 +457,7 @@
 
 
 
-int usb_ipw_init(void)
+static int usb_ipw_init(void)
 {
int retval;
 
@@ -473,7 +473,7 @@
return 0;
 }
 
-void usb_ipw_exit(void)
+static void usb_ipw_exit(void)
 {
usb_deregister(_ipw_driver);
usb_serial_deregister(_device);

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

[2.6 patch] drivers/usb/storage/: cleanups

This patch contains the following cleanups:
- make needlessly global code static
- scsiglue.c: remove the unused usb_stor_sense_notready

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

---

 drivers/usb/storage/scsiglue.c  |9 -
 drivers/usb/storage/scsiglue.h  |1 -
 drivers/usb/storage/shuttle_usbat.c |   13 -
 drivers/usb/storage/shuttle_usbat.h |4 
 drivers/usb/storage/transport.c |5 +++--
 drivers/usb/storage/transport.h |5 -
 drivers/usb/storage/usb.c   |4 ++--
 drivers/usb/storage/usb.h   |3 ---
 8 files changed, 13 insertions(+), 31 deletions(-)

--- linux-2.6.11-rc4-mm1-full/drivers/usb/storage/scsiglue.h.old
2005-02-28 23:17:23.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/storage/scsiglue.h2005-02-28 
23:18:41.0 +0100
@@ -48,7 +48,6 @@
 
 extern void usb_stor_report_device_reset(struct us_data *us);
 
-extern unsigned char usb_stor_sense_notready[18];
 extern unsigned char usb_stor_sense_invalidCDB[18];
 extern struct scsi_host_template usb_stor_host_template;
 
--- linux-2.6.11-rc4-mm1-full/drivers/usb/storage/scsiglue.c.old
2005-02-28 23:18:51.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/storage/scsiglue.c2005-02-28 
23:19:00.0 +0100
@@ -477,15 +477,6 @@
.module =   THIS_MODULE
 };
 
-/* For a device that is "Not Ready" */
-unsigned char usb_stor_sense_notready[18] = {
-   [0] = 0x70, /* current error */
-   [2] = 0x02, /* not ready */
-   [7] = 0x0a, /* additional length */
-   [12]= 0x04, /* not ready */
-   [13]= 0x03  /* manual intervention */
-};
-
 /* To Report "Illegal Request: Invalid Field in CDB */
 unsigned char usb_stor_sense_invalidCDB[18] = {
[0] = 0x70, /* current error */
--- linux-2.6.11-rc4-mm1-full/drivers/usb/storage/shuttle_usbat.h.old   
2005-02-28 23:20:36.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/storage/shuttle_usbat.h   
2005-02-28 23:20:55.0 +0100
@@ -105,10 +105,6 @@
 #define USBAT_FEAT_ET1 0x02
 #define USBAT_FEAT_ET2 0x01
 
-/* Transport functions */
-int usbat_hp8200e_transport(struct scsi_cmnd *srb, struct us_data *us);
-int usbat_flash_transport(struct scsi_cmnd * srb, struct us_data *us);
-
 extern int usbat_transport(struct scsi_cmnd *srb, struct us_data *us);
 extern int init_usbat(struct us_data *us);
 
--- linux-2.6.11-rc4-mm1-full/drivers/usb/storage/shuttle_usbat.c.old   
2005-02-28 23:19:48.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/storage/shuttle_usbat.c   
2005-02-28 23:22:52.0 +0100
@@ -61,7 +61,10 @@
 #define LSB_of(s) ((s)&0xFF)
 #define MSB_of(s) ((s)>>8)
 
-int transferred = 0;
+static int transferred = 0;
+
+static int usbat_flash_transport(struct scsi_cmnd * srb, struct us_data *us);
+static int usbat_hp8200e_transport(struct scsi_cmnd *srb, struct us_data *us);
 
 /*
  * Convenience function to produce an ATAPI read/write sectors command
@@ -872,8 +875,8 @@
 /*
  * Set the transport function based on the device type
  */
-int usbat_set_transport(struct us_data *us,
-   struct usbat_info *info)
+static int usbat_set_transport(struct us_data *us,
+  struct usbat_info *info)
 {
int rc;
 
@@ -1417,7 +1420,7 @@
 /*
  * Transport for the HP 8200e
  */
-int usbat_hp8200e_transport(struct scsi_cmnd *srb, struct us_data *us)
+static int usbat_hp8200e_transport(struct scsi_cmnd *srb, struct us_data *us)
 {
int result;
unsigned char *status = us->iobuf;
@@ -1560,7 +1563,7 @@
 /*
  * Transport for USBAT02-based CompactFlash and similar storage devices
  */
-int usbat_flash_transport(struct scsi_cmnd * srb, struct us_data *us)
+static int usbat_flash_transport(struct scsi_cmnd * srb, struct us_data *us)
 {
int rc;
struct usbat_info *info = (struct usbat_info *) (us->extra);
--- linux-2.6.11-rc4-mm1-full/drivers/usb/storage/transport.h.old   
2005-02-28 23:23:10.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/storage/transport.h   2005-02-28 
23:23:56.0 +0100
@@ -169,13 +169,8 @@
 extern int usb_stor_ctrl_transfer(struct us_data *us, unsigned int pipe,
u8 request, u8 requesttype, u16 value, u16 index,
void *data, u16 size);
-extern int usb_stor_intr_transfer(struct us_data *us, void *buf,
-   unsigned int length);
 extern int usb_stor_bulk_transfer_buf(struct us_data *us, unsigned int pipe,
void *buf, unsigned int length, unsigned int *act_len);
-extern int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,
-   struct scatterlist *sg, int num_sg, unsigned int length,
-   unsigned int *act_len);
 extern int usb_stor_bulk_transfer_sg(struct us_data

Re: [RFC] PCI bridge driver rewrite

2005-02-28 Thread Jesse Barnes

On Monday, February 28, 2005 4:13 pm, Adam Belay wrote:
> On Mon, 2005-02-28 at 15:38 -0800, Jesse Barnes wrote:
> > On Monday, February 28, 2005 3:27 pm, Adam Belay wrote:
> > > How can we specify which bus to target?
> >
> > Maybe we could have a list of legacy (ISA?) devices for drivers like
> > vgacon to attach to?  The bus info could be stuffed into the legacy
> > device structure itself so that the platform code would know what to do.
>
> Are these devices actually legacy, or PCI with compatibility interfaces?

So far I've only tried VGA cards, like radeons and r128s.

> I think a "struct isa_device" would be be useful.  Would a pointer to
> the "struct pci_bus" do the trick?

Yeah, that would work for me.

> I was just wondering if we have to reserve a memory range for this?

Sure, each bus can have that address range reserved.  The ia64 specific 
HAVE_PCI_LEGACY code (in arch/ia64/sn/pci/pci_dma.c I think) might illuminate 
things a bit.  Basically, each bus has legacy base addresses, we could 
reserve 64k for port space and 1M for memory.

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

[2.6 patch] drivers/usb/gadget/config.c: make a function static

This patch makes a needlessly global function static.

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

---

 drivers/usb/gadget/config.c |2 +-
 include/linux/usb_gadget.h  |6 --
 2 files changed, 1 insertion(+), 7 deletions(-)

--- linux-2.6.11-rc4-mm1-full/include/linux/usb_gadget.h.old2005-02-28 
23:15:09.0 +0100
+++ linux-2.6.11-rc4-mm1-full/include/linux/usb_gadget.h2005-02-28 
23:15:24.0 +0100
@@ -854,12 +854,6 @@
 
 /*-*/
 
-/* utility to simplify managing config descriptors */
-
-/* write vector of descriptors into buffer */
-int usb_descriptor_fillbuf(void *, unsigned,
-   const struct usb_descriptor_header **);
-
 /* build config descriptor from single descriptor vector */
 int usb_gadget_config_buf(const struct usb_config_descriptor *config,
void *buf, unsigned buflen, const struct usb_descriptor_header **desc);
--- linux-2.6.11-rc4-mm1-full/drivers/usb/gadget/config.c.old   2005-02-28 
23:15:34.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/usb/gadget/config.c   2005-02-28 
23:15:49.0 +0100
@@ -39,7 +39,7 @@
  * as part of configuring a composite device; or in other cases where
  * sets of descriptors need to be marshaled.
  */
-int
+static int
 usb_descriptor_fillbuf(void *buf, unsigned buflen,
const struct usb_descriptor_header **src)
 {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SELinux: Leak in error path

2005-02-28 Thread Alexander Nyberg

There's a leak here in the first error path.

Found by the Coverity tool.

Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>

= security/selinux/ss/conditional.c 1.3 vs edited =
--- 1.3/security/selinux/ss/conditional.c   2005-01-05 03:48:22 +01:00
+++ edited/security/selinux/ss/conditional.c2005-02-23 21:22:25 +01:00
@@ -401,8 +401,10 @@ static int cond_read_node(struct policyd
expr->expr_type = le32_to_cpu(buf[0]);
expr->bool = le32_to_cpu(buf[1]);
 
-   if (!expr_isvalid(p, expr))
+   if (!expr_isvalid(p, expr)) {
+   kfree(expr);
goto err;
+   }
 
if (i == 0) {
node->expr = expr;


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SELinux: null dereference in error path

2005-02-28 Thread Alexander Nyberg

The 'bad' label will call function that unconditionally dereferences
the NULL pointer.

Found by the Coverity tool

Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>

= security/selinux/ss/policydb.c 1.16 vs edited =
--- 1.16/security/selinux/ss/policydb.c 2005-01-15 23:01:45 +01:00
+++ edited/security/selinux/ss/policydb.c   2005-02-26 12:47:44 +01:00
@@ -773,7 +773,7 @@ static int class_read(struct policydb *p
cladatum = kmalloc(sizeof(*cladatum), GFP_KERNEL);
if (!cladatum) {
rc = -ENOMEM;
-   goto bad;
+   goto out;
}
memset(cladatum, 0, sizeof(*cladatum));
 


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

Re: [-mm patch] seccomp: don't say it was more or less mandatory

On Sat, Feb 26, 2005 at 02:31:37AM +0100, Andrea Arcangeli wrote:
> On Fri, Feb 25, 2005 at 10:14:54PM +0100, Adrian Bunk wrote:
> > You don't need this feature unless you know you need it.
> 
> But you may not know that you need it since in the help text I
> intentionally didn't mention which software requires the option to be
> set to Y (I didn't mention it, since I didn't want to use the kernel
> configuration help text to get free advertisement, but OTOH if people is
> unsure while they configure the kernel I certainly prefer that they set
> it to Y ;).
>...

If you want to use Cpushare, you know that you have to enable seccomp.

> Thanks.

cu
Adrian

-- 

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

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

[2.6 patch] SCSI: cleanups

Updated patch:

<--  snip  -->

This patch contains the following cleanups:
- make needlessly global code static
- remove the following unused functions:
  - scsi.h: print_driverbyte
  - scsi.h: print_hostbyte
- #if 0 the following unused functions:
  - constants.c: scsi_print_hostbyte
  - constants.c: scsi_print_driverbyte
- remove the following unneeded EXPORT_SYMBOL's:
  - hosts.c: scsi_host_lookup
  - scsi.c: scsi_device_cancel
  - scsi_lib.c: scsi_device_resume

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

---

 drivers/scsi/constants.c   |4 
 drivers/scsi/hosts.c   |3 +--
 drivers/scsi/scsi.c|9 +
 drivers/scsi/scsi.h|8 
 drivers/scsi/scsi_debug.c  |2 +-
 drivers/scsi/scsi_lib.c|5 ++---
 drivers/scsi/scsi_priv.h   |4 
 drivers/scsi/scsi_sysfs.c  |4 ++--
 include/scsi/scsi_dbg.h|2 --
 include/scsi/scsi_device.h |1 -
 10 files changed, 15 insertions(+), 27 deletions(-)

--- linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi.h.old   2005-02-28 
18:18:22.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi.h   2005-03-01 
00:58:19.0 +0100
@@ -80,14 +80,6 @@
 {
return scsi_print_req_sense(devclass, req);
 }
-static inline void print_driverbyte(int scsiresult)
-{
-   return scsi_print_driverbyte(scsiresult);
-}
-static inline void print_hostbyte(int scsiresult)
-{
-   return scsi_print_hostbyte(scsiresult);
-}
 static inline void print_status(unsigned char status)
 {
return scsi_print_status(status);
--- linux-2.6.11-rc4-mm1-full/include/scsi/scsi_dbg.h.old   2005-02-28 
18:17:32.0 +0100
+++ linux-2.6.11-rc4-mm1-full/include/scsi/scsi_dbg.h   2005-03-01 
01:01:25.0 +0100
@@ -11,8 +11,6 @@
 extern void __scsi_print_sense(const char *name,
   const unsigned char *sense_buffer,
   int sense_len);
-extern void scsi_print_driverbyte(int);
-extern void scsi_print_hostbyte(int);
 extern void scsi_print_status(unsigned char);
 extern int scsi_print_msg(const unsigned char *);
 extern const char *scsi_sense_key_string(unsigned char);
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/constants.c.old  2005-02-28 
18:17:46.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/constants.c  2005-03-01 
01:00:37.0 +0100
@@ -1393,6 +1393,8 @@
 }
 EXPORT_SYMBOL(scsi_print_command);
 
+#if 0
+
 #ifdef CONFIG_SCSI_CONSTANTS
 
 static const char * hostbyte_table[]={
@@ -1446,3 +1448,5 @@
printk("Driverbyte=0x%02x ", driver_byte(scsiresult));
 }
 #endif
+
+#endif  /*  0  */
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/hosts.c.old  2005-02-28 
18:33:14.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/hosts.c  2005-03-01 
00:58:19.0 +0100
@@ -56,7 +56,7 @@
  * @shost: pointer to struct Scsi_Host
  * recovery:   recovery requested to run.
  **/
-void scsi_host_cancel(struct Scsi_Host *shost, int recovery)
+static void scsi_host_cancel(struct Scsi_Host *shost, int recovery)
 {
struct scsi_device *sdev;
 
@@ -362,7 +362,6 @@
 
return shost;
 }
-EXPORT_SYMBOL(scsi_host_lookup);
 
 /**
  * scsi_host_get - inc a Scsi_Host ref count
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi_priv.h.old  2005-02-28 
19:59:30.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi_priv.h  2005-03-01 
00:58:19.0 +0100
@@ -66,8 +66,6 @@
 extern int scsi_dispatch_cmd(struct scsi_cmnd *cmd);
 extern int scsi_setup_command_freelist(struct Scsi_Host *shost);
 extern void scsi_destroy_command_freelist(struct Scsi_Host *shost);
-extern void scsi_done(struct scsi_cmnd *cmd);
-extern int scsi_retry_command(struct scsi_cmnd *cmd);
 extern int scsi_insert_special_req(struct scsi_request *sreq, int);
 extern void scsi_init_cmd_from_req(struct scsi_cmnd *cmd,
struct scsi_request *sreq);
@@ -141,7 +139,6 @@
 #endif /* CONFIG_SYSCTL */
 
 /* scsi_sysfs.c */
-extern void scsi_device_dev_release(struct device *);
 extern int scsi_sysfs_add_sdev(struct scsi_device *);
 extern int scsi_sysfs_add_host(struct Scsi_Host *);
 extern int scsi_sysfs_register(void);
@@ -150,7 +147,6 @@
 extern int scsi_sysfs_target_initialize(struct scsi_device *);
 extern struct scsi_transport_template blank_transport_template;
 
-extern struct class sdev_class;
 extern struct bus_type scsi_bus_type;
 
 /* 
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi.c.old   2005-02-28 
19:59:56.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi.c   2005-03-01 
00:58:19.0 +0100
@@ -68,6 +68,8 @@
 #include "scsi_priv.h"
 #include "scsi_logging.h"
 
+static void scsi_done(struct scsi_cmnd *cmd);
+static int scsi_retry_command(struct scsi_cmnd *cmd);
 
 /*
  * Definitions and constants.
@@ -90,7 +92,7 @@
 /*
  * Data declarations.
  */
-unsigned long scsi_pid;
+static unsigned long scsi_pid;
 static unsigned long serial_number;
 
 /*
@@ -733,7 +735,7 @@
  *
  * This function is

Re: [RFC] PCI bridge driver rewrite

On Mon, 2005-02-28 at 15:38 -0800, Jesse Barnes wrote:
> On Monday, February 28, 2005 3:27 pm, Adam Belay wrote:
> > How can we specify which bus to target?
> 
> Maybe we could have a list of legacy (ISA?) devices for drivers like vgacon 
> to 
> attach to?  The bus info could be stuffed into the legacy device structure 
> itself so that the platform code would know what to do.

Are these devices actually legacy, or PCI with compatibility interfaces?

I think a "struct isa_device" would be be useful.  Would a pointer to
the "struct pci_bus" do the trick?

> 
> > Also is the legacy IO space mapped to IO Memory on the other side of the
> > bridge?
> 
> How do you mean?  Legacy I/O port accesses just become strongly ordered 
> memory 
> transactions, afaik, and legacy memory accesses are dealt with the same way.
> 
> Jesse

I was just wondering if we have to reserve a memory range for this?

Thanks,
Adam


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] add driver matching priorities

On Fri, 2005-02-25 at 15:41 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
> > On Thu, 2005-02-10 at 18:45 +, Russell King wrote:
> > > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > > > I think the issue that Al raises about drivers grabbing devices, and
> > > > > then trying to unbind them might be a real problem.
> > > > 
> > > > I agree.  Do you think registering every in-kernel driver before probing
> > > > hardware would solve this problem?
> > > 
> > > In which case, consider whether we should be tainting the kernel if
> > > someone loads a device driver, it binds to a device, and then they
> > > unload that driver.
> > > 
> > > It's precisely the same situation, and precisely the same mechanics
> > > as what I've suggested should be going on here.  If one scenario is
> > > inherently buggy, so is the other.
> > > 
> > 
> > I think it would depend on whether the user makes the device busy before
> > the driver is unloaded.  Different device classes may have different
> > requirements for when and how a device can be removed.  Are there other
> > issues as well?  Maybe there are ways to improve driver start and stop
> > mechanics.
> 
> We never fail a device unbind from a driver, so this isn't as big a deal
> as I originally thought.  Yes, userspace can get messy, but as userspace
> was the one that loaded the new driver to bind, it's acceptable.
> 
> So, care to resubmit your patch?
> 

Would you like me to include the portion that adds "*match" to "struct
device_driver"?  After some more thought, I began considering having
driver priority be a static quality of a device driver.  The question is
whether we want a device driver to be able to return a variable priority
based on bind device.  Also, "*match" could be used to split some
detection and validation out of "*probe".  What are your reactions to
this?

Finally, should every in-kernel driver be registered before devices are
detected?

Thanks,
Adam


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] PCI bridge driver rewrite

On Fri, 2005-02-25 at 15:38 -0800, Greg KH wrote:
> On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:

> > I look forward to any comments or suggestions.
> 
> I like it all :)
> 
> If you want to submit patches now that rearrange the code to make it
> easier for you to modify in the future to achieve the above goals, feel
> free, I'll gladly take them.
> 
> thanks,
> 
> greg k-h

I'm going to do an updated release soon.  It should take care of some of
the issues on the TODO list and also will be based on previous feedback.
>From there, I'll start planning a strategy for merging with mainline.  I
appreciate the comments.

Thanks,
Adam


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

Re: Multichannel audio ?

2005-02-28 Thread Lee Revell

On Mon, 2005-02-28 at 18:24 -0500, Bill Davidsen wrote:
> Lee Revell wrote:
> > On Mon, 2005-02-28 at 15:13 +0100, [EMAIL PROTECTED] wrote:
> > 
> >>Hi!
> >>
> >>How does one use the extra channels on a six channel card ?
> >>I can only hear the 2 front speakers.
> > 
> > 
> > Off topic.  Please switch to ALSA (OSS is deprecated) then ask this
> > question on the ALSA lists.
> 
> What "the ALSA list" is that? I have asked the same question on 
> linux-sound several times and gotten no answer. If that list is dead it 
> should go away!
> 

Yes, it should.  linux-audio-user is active too. 

Lee

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

Re: SPARC64: Modular floppy?

2005-02-28 Thread David S. Miller

On Mon, 28 Feb 2005 17:07:43 -0300
Horst von Brand <[EMAIL PROTECTED]> wrote:

> So, either the dependencies have to get fixed so floppy can't be modular
> for this architecture, or the relevant functions have to move from entry.S
> to the module.

I think the former is the best solution.  The assembler code really
needs to get at floppy.c symbols.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] PCI bridge driver rewrite

On Thu, 2005-02-24 at 10:03 +, Russell King wrote:
> On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
> > 5.) write a bridge driver for Cardbus hardware
> 
> We have this already - it's called "yenta".

Yes, I'm aware.  It should read:

5.) adapt the Yenta driver to the new PCI bus class

:)

> 
> What you need to be aware of is that cardbus hardware is special - it
> may change its resource requirements at any time, both in terms of the
> number of BUS IDs it wishes to consume, and the number and size of
> IO and memory resources.

We can have default sizes allocated for these windows.  Maybe, we'll
even have rebalancing at some point.

As for BUS IDs, I'm not sure about the best behavior.  I don't really
like reserving 4 positions like we do now.  It has a tendency to create
conflicts, and seems to be unnecessary.  How common are PCI bridge
devices that attach to cardbus controllers?  Does the BIOS ever
preconfigure the cardbus bridge for this situation?  I think it's
important that we get bus numbering correct.  Some hardware has problems
now.

> 
> Note also that if a cardbus bridge isn't on the root bus (it happens on
> some laptops) these resource changes may impact on upstream bridges and
> devices.
> 

Yeah, also legacy resources can't pass through properly if the parent
bridge isn't transparent.  Complex bus topologies make the problem much
more difficult when legacy hardware is involved.

Thanks,
Adam

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

Re: Slowdown on high-load machines with 3000 sockets

2005-02-28 Thread Nick Piggin

Christian Schmid wrote:
This issue has been tracked down more. This bug does NOT appear if I 
disable preemtive kernel.
Maybe this helps.

Yes, it may help - can you boot with profile=schedule and get
the results for say, a 30 second period while the application
is experiencing problems?
So:
start application
wait till it hits slowdown
readprofile -r ; sleep 30 ; readprofile > schedprof.out
and send schedprof.out, please?
Thanks,
Nick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] PCI bridge driver rewrite

On Thu, 2005-02-24 at 02:25 -0500, Jon Smirl wrote: 
> When you start writing the PCI root bridge driver you'll run into the
> AGP drivers that are already attached to the bridge. I was surprised
> by this since I expected AGP to be attached to the AGP bridge but now
> I learned that it is a root bridge function.

I'm going to have the PCI root bridge driver bind to a device on the
primary side of the bridge.  The device could be enumerated by ACPI or
created manually when the bridge is detected.  It will not, however, be
a PCI device.

> 
> An ISA LPC bridge driver would be nice too. It would let you turn off
> serial ports, etc and let other systems know how many ports there are.
> No real need for this, just a nice toy.

I think this would make a lot of sense.  ACPI could be used to enumerate
child devices for this bridge.  I'd like to begin work on a generic ISA
bus driver soon.

> 
> Does this work to cause a probe based on PCI class?
> static struct pci_device_id p2p_id_tbl[] = {
>{ PCI_DEVICE_CLASS(PCI_CLASS_BRIDGE_PCI << 8, 0x00) },
>{ 0 },
> };

Yes, the macro is used when matching against only a class of device.

> 
> I would like to install a driver that gets called whenever new
> CLASS_VGA hardware shows up via hotplug. It won't attach to the
> device, it will just add some sysfs attributes. The framebuffer
> drivers need to attach the device. If I add attributes this way how
> can I remove them?

It would be possible, but probably not a clean solution.  Ideally we
want one driver to bind to the graphics controller and remain bound.  It
will then create class devices for each graphics subsystem, such as
framebuffer.  Much work remains to be done before this can happen.

Thanks,
Adam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] PCI bridge driver rewrite

2005-02-28 Thread Jesse Barnes

On Monday, February 28, 2005 3:27 pm, Adam Belay wrote:
> How can we specify which bus to target?

Maybe we could have a list of legacy (ISA?) devices for drivers like vgacon to 
attach to?  The bus info could be stuffed into the legacy device structure 
itself so that the platform code would know what to do.

> Also is the legacy IO space mapped to IO Memory on the other side of the
> bridge?

How do you mean?  Legacy I/O port accesses just become strongly ordered memory 
transactions, afaik, and legacy memory accesses are dealt with the same way.

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

Re: Multichannel audio ?

2005-02-28 Thread Nish Aravamudan

On Mon, 28 Feb 2005 18:24:40 -0500, Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Lee Revell wrote:
> > On Mon, 2005-02-28 at 15:13 +0100, [EMAIL PROTECTED] wrote:
> >
> >>Hi!
> >>
> >>How does one use the extra channels on a six channel card ?
> >>I can only hear the 2 front speakers.
> >
> >
> > Off topic.  Please switch to ALSA (OSS is deprecated) then ask this
> > question on the ALSA lists.
> 
> What "the ALSA list" is that? I have asked the same question on
> linux-sound several times and gotten no answer. If that list is dead it
> should go away!

[EMAIL PROTECTED] or [EMAIL PROTECTED], I would
guess, as per the ALSA homepage.

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

Re: Multichannel audio ?

2005-02-28 Thread Måns Rullgård

Bill Davidsen <[EMAIL PROTECTED]> writes:

> Lee Revell wrote:
>> On Mon, 2005-02-28 at 15:13 +0100, [EMAIL PROTECTED] wrote:
>>
>>>Hi!
>>>
>>>How does one use the extra channels on a six channel card ?
>>>I can only hear the 2 front speakers.
>> Off topic.  Please switch to ALSA (OSS is deprecated) then ask this
>> question on the ALSA lists.
>
> What "the ALSA list" is that?

Go to http://alsa-project.org/mailing-lists.php and pick one that
seems appropriate.

-- 
Måns Rullgård
[EMAIL PROTECTED]

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

Re: [PATCH 3/5] abstract discontigmem setup

2005-02-28 Thread Dave Hansen

The $SUBJECT patch has a small, obvious, compile bug in it on the
NUMA-Q, which I introduced while cleaning it up.  Please apply this
patch on top of that one.

-- Dave
The "abstract discontigmem setup" patch has a small compile bug in
it on the NUMA-Q, which I introduced while "cleaning it up."

Please apply after that patch.

Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---

 memhotplug-dave/arch/i386/kernel/numaq.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)

diff -puN arch/i386/kernel/numaq.c~A3.2.1-fix-numaq arch/i386/kernel/numaq.c
--- memhotplug/arch/i386/kernel/numaq.c~A3.2.1-fix-numaq	2005-02-28 14:16:23.0 -0800
+++ memhotplug-dave/arch/i386/kernel/numaq.c	2005-02-28 14:16:59.0 -0800
@@ -62,7 +62,9 @@ static void __init smp_dump_qct(void)
 
 			memory_present(node,
 node_start_pfn[node], node_end_pfn[node]);
-			node_remap_size[node] = node_memmap_size_bytes(node);
+			node_remap_size[node] = node_memmap_size_bytes(node,
+			node_start_pfn[node],
+			node_end_pfn[node]);
 		}
 	}
 }
_

Re: [RFC] PCI bridge driver rewrite

On Thu, 2005-02-24 at 15:02 -0800, Jesse Barnes wrote:
> On Wednesday, February 23, 2005 11:03 pm, Adam Belay wrote:
> 
> > > Jesse can comment on the specific support needed for multiple legacy IO
> > > spaces.
> >
> > That would be great.  Most of my experience has been with only a couple
> > legacy IO port ranges passing through the bridge.
> 
> Well, I'll give you one, somewhat perverse, example.  On SGI sn2 machines, 
> each host<->pci bridge (either xio<->pci or numalink<->pci) has two pci 
> busses and some additional host bus ports.  The bridges are capable of 
> generating low address bus cycles on both busses simultaneously, so we can do 
> ISA memory access and legacy port I/O on every bus in the system at the same 
> time.
> 
> The main host chipset has no notion of VGA or legacy routing though, so doing 
> a port access to say 0x3c8 is ambiguous--we need a bus to target (though the 
> platform code could provide a 'default' bus for such accesses to go to, this 
> may be what VGA or legacy routing means for us under your scheme).  Likewise, 
> accessing ISA memory space like 0xa needs a bus to target.
> 
> It would be nice if this sort of thing was taken into account in your new 
> model, so that for example we could have the vgacon driver talking to 
> multiple different VGA cards at the same time.
> 
> Thanks,
> Jesse

How can we specify which bus to target?  Also is the legacy IO space
mapped to IO Memory on the other side of the bridge?

Thanks,
Adam


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

Re: status of the USB ov511.c driver in kernel 2.6?

2005-02-28 Thread Richard Hughes

On Mon, 28 Feb 2005 23:48:13 +0100, Adrian Bunk wrote:
> - there's no *_decomp.c module in the kernel sources

If I remember correctly people are bit uneasy about putting
decompression of proprietary codecs into to the kernel.

See
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg04778.html

Every kernel release I end up building an external module just to get my
OV518 usb webcam to work. (It requires decompression support) Not cool.

> Are there any reasons why the upstream driver can't be resynced with the 
> kernel?

I think ovcamchip is from the development branch, but ov511 is from the
stable branch. Not sure about that. Best bet is contact Mark McClelland
(maintainer) here:

mmcclell  calpoly.edu 
or mark  alpha.dyndns.org

Richard Hughes

-- 

http://www.hughsie.com/PUBLIC-KEY

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

Re: Multichannel audio ?

Lee Revell wrote:
On Mon, 2005-02-28 at 15:13 +0100, [EMAIL PROTECTED] wrote:
Hi!
How does one use the extra channels on a six channel card ?
I can only hear the 2 front speakers.

Off topic.  Please switch to ALSA (OSS is deprecated) then ask this
question on the ALSA lists.
What "the ALSA list" is that? I have asked the same question on 
linux-sound several times and gotten no answer. If that list is dead it 
should go away!

--
   -bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc4-mm1: something is wrong with swsusp powerdown

2005-02-28 Thread Pavel Machek

Hi!

In `subj` kernel, machine no longer powers down at the end of
swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk.

Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

status of the USB w9968cf.c driver in kernel 2.6?

I noticed the following regarding the drivers/usb/media/ov511.c driver:
- it's not updated compared to upstream:
- there's no w9968cf-vpp module in the kernel sources

Are there any reasons why the upstream driver can't be resynced with the
kernel?

cu
Adrian

-- 

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

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

Re: Potentially dead bttv cards from 2.6.10

James Bruce wrote:
Well, are there any theories as to why it would work flawlessly, then 
after a hard lockup (due to what I think is a buggy V4L2 application), 
that the cards no longer work?  That was with 2.6.10, but after they 
started failing I tried 2.6.11-rc5 and it doesn't work either.  By the 
way, I sent the wrong output; what I sent was from 2.6.11-rc5.  The 
2.6.10 output is below, and looks similar except for generating a 
different error message.
Is there any chance that the lockup was related to an external event, 
like a spike on the line to the video? Or any other outside event? It 
seems like a very odd failure mode, but since I'm about to drop in a 
bttv card and digitize about a hundred old tapes, I'd like to know.

Did you try the "card=" suggestion?
--
   -bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 patch] SCSI: possible cleanups

On Mon, Feb 28, 2005 at 10:25:09PM +, Christoph Hellwig wrote:
>...
> >   - constants.c: scsi_print_hostbyte
> >   - constants.c: scsi_print_driverbyte
> 
> these we'll probably keep for now.
>...

keep = #if 0 ?

cu
Adrian

-- 

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

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

Generic IRQ handling

2005-02-28 Thread Daniel Walker


There is a change to the generic IRQ handling in the ARM RT patch (as of
today) that should be discussed here.

I added a macro define called __ARCH_HAS_IRQ_DESC_T that removes the
generic irq_desc_t and hw_irq_controller if the architecture has them
defined already. I don't see any problems with this, and it makes ARM
integration a little easier . 

I also modified the make files so that individual files in kernel/irq/
can be compiled depending on config options. 

The full ARM RT patch is here,

ftp://source.mvista.com/pub/realtime/arm/common_arm_realtime.patch

Daniel Walker

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

Re: [CAN-2005-0204]: AMD64, allows local users to write to privileged IO ports via OUTS instruction

2005-02-28 Thread Dave Jones

On Mon, Feb 28, 2005 at 02:20:11PM -0800, Chris Wright wrote:
 > * micah milano ([EMAIL PROTECTED]) wrote:
 > > CAN-2005-0204 reads:
 > 
 > [snip]
 > 
 > > This apparantly only affects AMD64 and EM64T.
 > 
 > It also does not effect mainstream kernels.  IIRC, it turns out to be
 > a problem introduced with 4G/4G patch which is not in mainline.

Correct.

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/

[2.6.11-rc4-bk9] Bad behaviour using RAID

I just added a few more 200GB drives on a Promise controller, and they 
are configured as:
  md0 - raid1, 6GB of stuff I really don't want to lose 64k stripe
  md1 - raid0, 350GB for streaming video capture, 512k stripe
This space was configured with "mdadm" if that makes a difference, and I 
didn't get the right options to make it start at boot, so it gets run 
out of rc.local. I doubt that makes a difference, but I mention it.

Since this machine is often idle for hours, I have the two drives of 
interest set to spin down after 20 minutes of disuse. Other than a 
fairly slow start I have had no problems with restarting after an idle 
period.

There are no problems with data corruption or error messages, nor have I 
ever see any indication of a rebuild in progress. HOWEVER, every once in 
a while the disk light comes on and the system becomes very 
unresponsive. Since the Promise controller isn't connected to the disk 
light, the activity is one the original (120gb, 200gb) drives somewhere. 
The system is unresponsive for 1-2 minutes, although not totally so, I 
can look at /proc/mdstat and see no rebuild, and even guess that the 
raid drives are spun down because access takes seconds after the system 
seems normal.

The system was up since the night the kernel was released, and I never 
saw any such behaviour until I added the other drives, but the activity 
is not on the new drives. This happens 1-2 times a day by observation, 
and since I use the system remotely during the week, I can only say that 
I haven't seen the unresponsive behaviour before, nor observed it on the 
weekend in the office. If I see it several times a day it's likely to be 
happening more often.

If anyone has even the slightest clue what's happening, I'd love to hear 
it. It started when the new hardware was added, but occurs on the old.

--
   -bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

status of the USB ov511.c driver in kernel 2.6?

I noticed the following regarding the drivers/usb/media/ov511.c driver:
- it's not updated compared to upstream:
  - version 1.64 is neither version 2 nor the latest 1.x version 1.65
- there's no *_decomp.c module in the kernel sources

Are there any reasons why the upstream driver can't be resynced with the 
kernel?

cu
Adrian

-- 

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

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

Re: [WATCHDOG] correct sysfs name for watchdog devices

2005-02-28 Thread Henrik Brix Andersen

On Sun, 2005-02-27 at 21:39 +0100, Wim Van Sebroeck wrote:
>  drivers/char/watchdog/scx200_wdt.c  |2 +-

This particular change is also included in my scx200 patch:
http://dev.gentoo.org/~brix/files/net4801/linux-2.6.11-rc5-scx200.patch
   
>Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
>Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Signed-off-by: Henrik Brix Andersen <[EMAIL PROTECTED]>

./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Linux


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

Re: Support for GEODE CPU's in Kernel 2.6.10.

2005-02-28 Thread Henrik Brix Andersen

On Sun, 2005-02-27 at 23:11 +0100, Kianusch Sayah Karadji wrote:
> This is a small patch for GEODE CPU support in Kernel 2.6.10.

I would very much welcome the addition of MGEODE. The in-kernel SCx200
drivers could also benefit from this (they should depend on MGEODE).

Signed-off-by: Henrik Brix Andersen <[EMAIL PROTECTED]>

./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Linux


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

Re: [PATCH 2.6.11-rc4] oom_kill.c: Kill obvious processes first