Re: 2.6.11-rc2-mm2

[Andrew Morton]

Paul Blazejowski <[EMAIL PROTECTED]> wrote:
>
> Kernel compile errors here, i think this might be XFS related...
> 
>  fs/built-in.o(.text+0x52a93): In function `linvfs_decode_fh':
>  : undefined reference to `find_exported_dentry'
>  make: *** [.tmp_vmlinux1] Error 1

bix:/home/akpm> grep EXPORT x
CONFIG_XFS_EXPORT=y
CONFIG_EXPORTFS=m

That isn't going to work.  Something like this, perhaps?

--- 25/fs/xfs/Kconfig~a 2005-01-29 23:55:53.643674392 -0800
+++ 25-akpm/fs/xfs/Kconfig  2005-01-29 23:56:26.435689248 -0800
@@ -22,7 +22,8 @@ config XFS_FS
 
 config XFS_EXPORT
bool
-   default y if XFS_FS && EXPORTFS
+   depends on XFS_FS
+   select EXPORTFS
 
 config XFS_RT
bool "Realtime support (EXPERIMENTAL)"
_

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

Re: Fwd: Patch to control VGA bus routing and active VGA device.

[Jon Smirl]

On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
> And yes, I agree that this needs to be done, I've been talking with a
> few other people who are interested in it.  I think the lock-rework code
> needs to be finished before it can happen properly, so that we can do
> the "unbind from one driver and give it to another one" type logic
> properly.

Unbind/give does not address what VGA control needs. VGA control needs
to track hotplug remove events so that it can route the display to
another VGA card if the active display is pulled. As far as I can tell
there is no way to monitor hotplug remove events, that's why I had to
add a callout in pci_destroy_dev().

VGA control also can't just install a device driver since that will
prevent the real DRM/FB device drivers from installing. It looks to me
like VGA control is more of a strange property of the PCI bus
architecture than a device driver.

Another strategy would be to create the concept of a PCI class driver
which a normal device driver would inherit from instead of replacing
it. But is there a need for another PCI class driver other than VGA?


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

Re: 2.6.11-rc2-mm2

[Paul Blazejowski]

Kernel compile errors here, i think this might be XFS related...

fs/built-in.o(.text+0x52a93): In function `linvfs_decode_fh':
: undefined reference to `find_exported_dentry'
make: *** [.tmp_vmlinux1] Error 1

.config attached

Cheers,

Paul B.

-- 
FreeBSD the Power to Serve!


.config
Description: Binary data

Re: 2.6.11-rc2-mm2

[Andrew Nelson]

I got a compile error:
arch/x86_64/kernel/asm-offsets.c: In function `main':
arch/x86_64/kernel/asm-offsets.c:65: error: invalid application of
`sizeof' to incomplete type `pbe'
arch/x86_64/kernel/asm-offsets.c:66: error: dereferencing pointer to
incomplete type
arch/x86_64/kernel/asm-offsets.c:67: error: dereferencing pointer to
incomplete type
make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 1
make: *** [arch/x86_64/kernel/asm-offsets.s] Error 2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH, 2.6.11-rc2-RT] Proprietary ATI Radeon Drivers

[John Gilbert]

Hello all,
These patches allow ATI's Radeon drivers (8.8.25) to work under the 
realtime-preempt 2.6.11-rc2-v0.7.37-01 Linux kernels.

Be sure to configure tmpfs before using (see 
http://www.ati.com/support/infobase/4687.html).

OpenGL works very well. Quake 3, bzflag, gltron all run solidly and 
smoothly!
Exiting X Windows blanks screen until next reboot.
There are still some compile time warnings that should be fixed.
An OpenGL latency footprint / histogram and performance test suite 
should be developed.
The open code parts of ATI's drivers need to be picked through for 
spinlocks, and cleaned up if possible.
Lots of other work left to do, like a frame scheduler locked to page 
redraw interrupts, Xv support, a triple buffering API (next version of SDL?)

Please send me any improvements. Thanks.
John Gilbert
[EMAIL PROTECTED]
--- agpgart_be.c.orig   2004-12-14 09:55:47.0 -0800
+++ agpgart_be.c2005-01-24 17:09:15.0 -0800
@@ -117,6 +117,10 @@
 #include 
 #include 
 
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,9)
+#define pci_find_class pci_get_class
+#endif
+
 #if (LINUX_VERSION_CODE >= 0x020400)
 #define FGL_PM_PRESENT
 #else
@@ -6469,6 +6473,7 @@
 
 // FGL - end
 
+#ifdef __x86_64__
 static int agp_check_supported_device(struct pci_dev *dev) 
 {
 
@@ -6483,13 +6488,16 @@
 
   return 0;
 }
+#endif
 
 /* Supported Device Scanning routine */
 
 static int __init agp_find_supported_device(void)
 {
struct pci_dev *dev = NULL;
+#ifdef __x86_64__
 u8 cap_ptr = 0x00;
+#endif
 
 // locate host bridge device
 #ifdef __x86_64__
--- firegl_public.c.orig2005-01-04 17:05:05.0 -0800
+++ firegl_public.c 2005-01-24 16:50:28.0 -0800
@@ -2590,13 +2590,13 @@
 #endif /* __ia64__ */
 vma->vm_flags |= VM_IO; /* not in core dump */
 }
-if (remap_page_range(FGL_VMA_API_PASS
+if (remap_pfn_range(FGL_VMA_API_PASS
  vma->vm_start,
- __ke_vm_offset(vma),
+ vma->vm_pgoff,
  vma->vm_end - vma->vm_start,
  vma->vm_page_prot))
 {
-__KE_DEBUG("remap_page_range failed\n");
+__KE_DEBUG("remap_pfn_range failed\n");
 return -EAGAIN;
 }
 vma->vm_flags |= VM_SHM | VM_RESERVED; /* Don't swap */
@@ -2655,15 +2655,15 @@
 #else
//  else
{
-   if (__ke_vm_offset(vma) >= __pa(high_memory))
+   if (vma->vm_pgoff >= __pa(high_memory))
vma->vm_flags |= VM_IO; /* not in core 
dump */
-   if (remap_page_range(FGL_VMA_API_PASS
+   if (remap_pfn_range(FGL_VMA_API_PASS
 
vma->vm_start,
-
__ke_vm_offset(vma),
+
vma->vm_pgoff,
 
vma->vm_end - vma->vm_start,
 
vma->vm_page_prot))
{
-   __KE_DEBUG("remap_page_range failed\n");
+   __KE_DEBUG("remap_pfn_range failed\n");
return -EAGAIN;
}
 #ifdef __x86_64__
@@ -2692,15 +2692,15 @@
 // else
 #else
{
-   if (__ke_vm_offset(vma) >= __pa(high_memory))
+   if (vma->vm_pgoff >= __pa(high_memory))
vma->vm_flags |= VM_IO; /* not in core 
dump */
-   if (remap_page_range(FGL_VMA_API_PASS
+   if (remap_pfn_range(FGL_VMA_API_PASS
 
vma->vm_start,
-
__ke_vm_offset(vma),
+
vma->vm_pgoff,
 
vma->vm_end - vma->vm_start,
 
vma->vm_page_prot))
{
-   __KE_DEBUG("remap_page_range failed\n");
+   __KE_DEBUG("remap_pfn_range failed\n");
return -EAGAIN;
}
 #ifdef __x86_64__
@@ -2744,6 +2744,20 @@
 
 #if LINUX_VERSIO

irq 10: nobody cared! (bug with IDE, Promise PDC20265 controller)

[Rogério Brito]

Dear developers,

I bought myself a DVD recorder yesterday and today I tried to install it in
my system. I have an Asus A7V motherboard with a VIA KT133 chipset with 2
VIA IDE controllers and 2 Promise PDC20265 controllers.

Since I already had a CD recorder, I decided to keep it and I tried to
configure the things as:

/dev/hda: the DVD recorder (in ide0, a VIA controller);
/dev/hdc: the CD recorder (in ide1, also a VIA controller);
/dev/hde: a 13GB HD (in ide2, a Promise PDC20265 controller);
/dev/hdg: a 30GB HD (in ide3, also a PDC20265 controller).

Unfortunately, right upon boot with my kernel 2.6.11-rc2, I got a stack
trace saying that "irq 10: nobody cared!" and a whole lot of lines
regarding to the promise controller. My kernel didn't have ACPI enabled
(only APM).

I then tried to compile a 2.6.11-rc2-mm2 kernel with ACPI enabled and that
didn't solve the problem.

Could anybody help, please? I don't know what is the relevant information,
but I am attaching the dmesg of the 2.6.11-rc2-mm2 kernel. BTW, it
suggested that I booted with the irqpoll option, which I did, but the
problem persisted.

If you need more information, please don't hesistate to ask.


Thanks in advance for any help, Rogério Brito.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Linux version 2.6.11-rc2-mm2-1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 
1:3.3.5-5)) #1 Sun Jan 30 01:40:01 BRST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009e800 (usable)
 BIOS-e820: 0009e800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0ffec000 (usable)
 BIOS-e820: 0ffec000 - 0ffef000 (ACPI data)
 BIOS-e820: 0ffef000 - 0000 (reserved)
 BIOS-e820: 0000 - 1000 (ACPI NVS)
 BIOS-e820:  - 0001 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65516
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 61420 pages, LIFO batch:14
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 ASUS  ) @ 0x000f6a90
ACPI: RSDT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec000
ACPI: FADT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec080
ACPI: BOOT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec040
ACPI: DSDT (v001   ASUS A7V  0x1000 MSFT 0x010b) @ 0x
Built 1 zonelists
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to d000 (01201000)
Initializing CPU#0
Kernel command line: BOOT_IMAGE=linux root=2103 irqpoll
Misrouted IRQ fixup and polling support enabled.
This may significantly impact system performance.
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 605.414 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 255708k/262064k available (2137k kernel code, 5796k reserved, 721k 
data, 168k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1183.74 BogoMIPS (lpj=591872)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183f9ff c1c7f9ff    
 
CPU: After vendor identify, caps: 0183f9ff c1c7f9ff    
 
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After all inits, caps: 0183f9ff c1c7f9ff  0020  
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Duron(tm) Processor stepping 00
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0e20)
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050125
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Via IRQ fixup
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** wor

Re: [PATCH] relayfs redux, part 2

[Tom Zanussi]

Greg KH writes:
 > On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
 > > +extern void * alloc_rchan_buf(unsigned long size,
 > > +struct page ***page_array,
 > > +int *page_count);
 > > +extern void free_rchan_buf(void *buf,
 > > + struct page **page_array,
 > > + int page_count);
 > 
 > As these will be "polluting" the global namespace of the kernel, could
 > you add "relayfs_" to the front of them?
 > 
 > Also, any reason why you haven't exported the fops of relayfs so that
 > others can use this in their filesystems (like proc and debugfs)?
 > 

No reason - I just forgot.  I'll make sure that gets fixed along with
all the other things you pointed out here in the next patch.

Thanks,

Tom


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

Re: [PATCH] relayfs redux, part 2

[Tom Zanussi]

Andi Kleen writes:
 > Tom Zanussi <[EMAIL PROTECTED]> writes:
 > 
 > > Hi,
 > >
 > > This patch is the result of the latest round of liposuction on relayfs
 > > - the patch size is now 44K, down from 110K and the 200K before that.
 > > I'm posting it as a patch against 2.6.10 rather than -mm in order to
 > > make it easier to review, but will create one for -mm once the changes
 > > have settled down.
 > 
 > The logging fast path seems still a bit slow to me. I would like
 > to have a logging macro that is not much worse than a stdio putc,
 > basically something like
 > 
 >   get_cpu();
 >   if (buffer space > N) { 
 >   memcpy(buffer, input, N);
 >   buffer pointer += N;
 >   } else { 
 >   FreeBuffer(input, N); 
 >   }
 >   put_cpu();
 > 

I think what we have now is somewhat similar, except that we wanted to
separate grabbing a slot in the buffer from the memcpy because some
applications such as ltt want to be able to directly write into the
slot without having to copy it into another buffer first.  How about
something like this for relay reserve, with the local_add_return()
gone since we're assuming the client protects the buffer properly for
whatever it's doing:

relay_reserve(length)
{
if (buffer->offset + length <= bufsize) {
reserved = buffer->data + buffer->offset;
buffer->offset += length;
} else { /* slow path */
reserved = switch_buffer(length);
if (reserved)
buffer->offset += length;
}

return reserved;
}

If you set up the channel to use MODE_CONTINUOUS, meaning continuously
cycle around the buffer, your logging function or macro would look
something like this:

simplest_write(data, length)
{
get_cpu();

reserved = relay_reserve();
memcpy(reserved, data, length);

put_cpu();
}

Clients who want to stop logging if the buffers are full would have an
extra test for when the reserve fails, which can never happen in
continuous mode:

/* uses MODE_NO_OVERWRITE */
ltt_write(data, length)
{
local_irq_save();

reserved = relay_reserve();
if (reserved) { /* if NULL, buffer full */
memcpy(reserved, item1, len1);
.
.
.
memcpy(reserved, itemN, lenN);
}

local_irq_restore();
}

 > This would need interrupt protection only if interrupts can access
 > it, best you use separate buffers for that too.

Not sure what you mean by separate buffers for that too.  Can you
expand on that a little?

Thanks,

Tom

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

Re: [PATCH 6/8] Kconfig: cleanup input menu

[Dmitry Torokhov]

On Saturday 29 January 2005 22:22, Roman Zippel wrote:
> Hi,
> 
> On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
> 
> > Well, with the current Kconfig I can de-select INPUT and still select
> > serio and serio_raw and access my AUX port via /dev/psaux. I don't know
> > if anyone would really do it, but why not?
> > 
> > Btw, what was the point of your patch?
> 
> See the subject. The current input Kconfig menu is already quite complex 
> for a lot of people, we don't have to confuse them further with a chaotic 
> menu structure. I only did the minimal fixes to get it into proper shape 
> with an acceptable compromise. Feel free to take it from here to also make 
> it technically correct.
> 

Ok, what about making some submenus to manage number of options, like in
the patch below?

-- 
Dmitry

= drivers/input/Kconfig 1.8 vs edited =
--- 1.8/drivers/input/Kconfig   2005-01-15 17:31:06 -05:00
+++ edited/drivers/input/Kconfig2005-01-29 22:53:30 -05:00
@@ -4,8 +4,14 @@
 
 menu "Input device support"
 
+comment "Hardware I/O ports"
+
+source "drivers/input/serio/Kconfig"
+
+source "drivers/input/gameport/Kconfig"
+
 config INPUT
-   tristate "Input devices (needed for keyboard, mouse, ...)" if EMBEDDED
+   tristate "Generic input layer (needed for keyboard, mouse, ...)" if 
EMBEDDED
default y
---help---
  Say Y here if you have any input device (mouse, keyboard, tablet,
@@ -23,6 +29,7 @@
  module will be called input.
 
 comment "Userland interfaces"
+   depends on INPUT
 
 config INPUT_MOUSEDEV
tristate "Mouse interface" if EMBEDDED
@@ -134,13 +141,8 @@
  To compile this driver as a module, choose M here: the
  module will be called evbug.
 
-comment "Input I/O drivers"
-
-source "drivers/input/gameport/Kconfig"
-
-source "drivers/input/serio/Kconfig"
-
 comment "Input Device Drivers"
+   depends on INPUT
 
 source "drivers/input/keyboard/Kconfig"
 
= drivers/input/gameport/Kconfig 1.5 vs edited =
--- 1.5/drivers/input/gameport/Kconfig  2005-01-08 00:43:50 -05:00
+++ edited/drivers/input/gameport/Kconfig   2005-01-29 22:50:38 -05:00
@@ -1,6 +1,8 @@
 #
 # Gameport configuration
 #
+menu "Gameport support"
+
 config GAMEPORT
tristate "Gameport support"
---help---
@@ -88,3 +90,4 @@
tristate "Crystal SoundFusion gameport support"
depends on GAMEPORT
 
+endmenu
= drivers/input/joystick/Kconfig 1.10 vs edited =
--- 1.10/drivers/input/joystick/Kconfig 2005-01-27 02:13:43 -05:00
+++ edited/drivers/input/joystick/Kconfig   2005-01-29 22:59:51 -05:00
@@ -1,6 +1,8 @@
 #
 # Joystick driver configuration
 #
+menu "Joysticks"
+
 config INPUT_JOYSTICK
bool "Joysticks"
depends on INPUT
@@ -258,3 +260,4 @@
  To compile this driver as a module, choose M here: the
  module will be called joydump.
 
+endmenu
= drivers/input/keyboard/Kconfig 1.15 vs edited =
--- 1.15/drivers/input/keyboard/Kconfig 2004-09-22 01:48:17 -05:00
+++ edited/drivers/input/keyboard/Kconfig   2005-01-29 22:59:34 -05:00
@@ -1,6 +1,8 @@
 #
 # Input core configuration
 #
+menu "Keyboards"
+
 config INPUT_KEYBOARD
bool "Keyboards" if EMBEDDED || !X86
default y
@@ -97,3 +99,5 @@
 
  To compile this driver as a module, choose M here: the
  module will be called amikbd.
+
+endmenu
= drivers/input/misc/Kconfig 1.11 vs edited =
--- 1.11/drivers/input/misc/Kconfig 2005-01-15 17:31:06 -05:00
+++ edited/drivers/input/misc/Kconfig   2005-01-29 23:04:17 -05:00
@@ -1,6 +1,8 @@
 #
 # Input misc drivers configuration
 #
+menu "Miscellaneous devices"
+
 config INPUT_MISC
bool "Misc"
depends on INPUT
@@ -49,3 +51,4 @@
  To compile this driver as a module, choose M here: the
  module will be called uinput.
 
+endmenu
= drivers/input/mouse/Kconfig 1.21 vs edited =
--- 1.21/drivers/input/mouse/Kconfig2005-01-15 17:31:06 -05:00
+++ edited/drivers/input/mouse/Kconfig  2005-01-29 23:01:25 -05:00
@@ -1,6 +1,8 @@
 #
 # Mouse driver configuration
 #
+menu "Mice"
+
 config INPUT_MOUSE
bool "Mice"
default y
@@ -129,3 +131,4 @@
  described in the source file). This driver also works with the
  digitizer (VSXXX-AB) DEC produced.
 
+endmenu
= drivers/input/serio/Kconfig 1.21 vs edited =
--- 1.21/drivers/input/serio/Kconfig2005-01-04 11:16:51 -05:00
+++ edited/drivers/input/serio/Kconfig  2005-01-29 22:48:56 -05:00
@@ -1,12 +1,14 @@
 #
 # Input core configuration
 #
+menu "PS/2 and serial port support"
+
 config SERIO
-   tristate "Serial i/o support" if EMBEDDED || !X86
+   tristate "Serial I/O support" if EMBEDDED || !X86
default y
---help---
  Say Yes here if you have any input device that uses serial I/O to
- communicate with the system. This includes the 
+ communicate with the system. This includes the

Re: [PATCH 6/8] Kconfig: cleanup input menu

[Roman Zippel]

Hi,

On Sat, 29 Jan 2005, Dmitry Torokhov wrote:

> Well, with the current Kconfig I can de-select INPUT and still select
> serio and serio_raw and access my AUX port via /dev/psaux. I don't know
> if anyone would really do it, but why not?
> 
> Btw, what was the point of your patch?

See the subject. The current input Kconfig menu is already quite complex 
for a lot of people, we don't have to confuse them further with a chaotic 
menu structure. I only did the minimal fixes to get it into proper shape 
with an acceptable compromise. Feel free to take it from here to also make 
it technically correct.

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

Using fuse for AFS/DFS (was Re: [OpenAFS-devel] openafs / opendfs collaboration)

[Luke Kenneth Casson Leighton]

On Fri, Jan 28, 2005 at 03:45:08PM +0100, Alexander Bostr?m wrote:
> fre 2005-01-21 klockan 12:22 -0500 skrev Derrick J Brashear: 
> > On Fri, 21 Jan 2005, Matthew Miller wrote:
> > 
> > > On Fri, Jan 21, 2005 at 09:00:59AM -0500, Derrick J Brashear wrote:
> 
> > >> It seems like Arla would probably have a better model for us all to 
> > >> follow
> > >> if we did so.
> > >
> > > Or on Linux, something based on FUSE, which is apparently now getting
> > > merged.
> > 
> > Arla's nnpfs is actually portable, one filesystem per platform sort of 
> > sucks.
> 
> But it lacks a nice libnnpfs that one can use to implement a filesystem.
> 
> Every OS should have some kind of userland filesystem interface. Linux
> might get FUSE (and it might be adequate*), HURD has one, Dragonfly are
> aiming at it and on some systems there's nnpfs already. On top of those
> interfaces there could be a set of libraries implementing a common API
> for all the platforms.
> 
> *) Last time I looked at FUSE the security model was: If the current uid
> equals the owner of the mountpoint then forward the request to the
> userland daemon, without any authentication information like for example
> the current uid. This might have or could be changed though.

 as of 2.6.7-ish (last time i looked: 2.5 months) there was
 no forwarding of security: in fact there was nothing in any of the
 APIs about security at all: in fact, root as a user was banned (with
 good justification iirc)

 also, the xattr handling was (is?) non-existant and i had to
 add it, but it was unsuitable for selinux, and that's a design
 mismatch between fuse's way of communicating with its userspace
 daemon (err -512 "please try later") and selinux's requirement
 for instant answers (inability to cope with err -512)

 so i started to look at lufs instead, which appeared to be a much
 cleaner design.

 lufs expects the userspace daemon to handle and manage inodes,
 whereas fuse instead keeps an in-memory cache of inodes in
 the userspace daemon, does a hell of a lot of extra fstat'ing
 for you in order to guarantee file consistency, that sort of thing.

 there is an API / library which your userspace daemon is expected to
 use: this library handles the communication to the kernel and also it
 handles the inode proxy redirection and cacheing for you.

 lufs has a heck of a lot more examples available for it than fuse
 does.

 that all having been said, i don't think lufs's API has any
 security handling either.

 six of one, half a dozen of the other, but if you wanted fuse
 to support selinux and any other form of security that involves
 extended attributes, you would definitely have problems: i didn't get
 round to evaluating lufs for selinux (ran out of time and money).

 l.

--
http://lkcl.net";>http://lkcl.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: I need a hardware wizard... I have been beating my head on the wall..

[David Sims]

Hello people,

  Now I _really_ need to bang my head on the wall... :(  and thank all
you people who responded to my cry for help... I have to admit that I have
been stupid (or just a little clueless) but I have worked the puzzle!!

  It seems that sata_vsc works just fine My entire problem involved
the PCI IRQ routing mechanism and my lack of understanding of the
interaction between 'Loacl APIC', 'IO-APIC' and power management It
seems that you can do what you want with 'Local APIC' and 'IO-APIC' but if
you have not enabled ACPI, the APIC stuff is not enabled... and doesn't
seem to do anything

  I have now enabled both ACPI and APIC (with IO-APIC)  and the IRQ
barking has gone away!! 

  I had a similar problem today with another computer (ASUS
MS4800-MX) where the built in Ethernet on a Via PHY chip (supported by the
SiS900 driver) refused to work... In this case I booted up Knoppix which
worked just fine and then started trying to figure out why there was a
difference between knoppix and a vanilla Slackware kernel It seems
that Slackware 9.1 does not have ACPI (or APIC or IO-APIC) enabled... Once
I figured that out, it was seemed to make the SIS900 driver work so I
decided to try it on the sata_vsc problem The result is history and
everything is working as it should It's a shame that the knoppix 3.4
kernel doesn't probe for SATA stuff or I would probably have figured this
out a week ago :(

  Meanwhile, a working sata_vsc allows one to turn a Dell Powervault 745N
(Dell's foray into Network Attached Storage) into a good and cheap unix
server with dual gig NICs and 4 SATA disks that can either be run
independently or via software raid!! Cool!

Thanks again for your support for and patience with me... I will be humble
for a while now... ;)

Dave






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

Re: [PATCH 6/8] Kconfig: cleanup input menu

[Dmitry Torokhov]

On Saturday 29 January 2005 20:16, Roman Zippel wrote:
> Hi,
> 
> On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
> 
> > > That's fine, but why is it in the input menu? How do you suggest to make 
> > > it selectable without selecting input and without messing the menu 
> > > structure?
> > 
> > Well, probably split input into sections, one of the options would be
> > something like "Generic Input Layer" and have evdev, mousedev, etc
> > depend on it. serio will not depend on it... nor will gameport as
> > I can see someone wanting gameport_raw.
> 
> That's not the point of my patch. Feel free to restructure the input menu, 
> if you need help you can ask me, but is there any practically relevant 
> reason, that serio_raw must not depend on INPUT right now?
> 

Well, with the current Kconfig I can de-select INPUT and still select
serio and serio_raw and access my AUX port via /dev/psaux. I don't know
if anyone would really do it, but why not?

Btw, what was the point of your patch?
 

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

[PATCH 2.6.11-rc2] I2C: lm80 driver improvement - again...

[Shawn Starr]

Description: Cleanup some cluttered macros, add error checking for fan divisor 
value set.

Signed-off-by: Sytse Wielinga <[EMAIL PROTECTED]>
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Shawn Starr <[EMAIL PROTECTED]>


Description: Cleanup some cluttered macros, add error checking for fan divisor 
value set.

Approved-by: Greg KH <[EMAIL PROTECTED]>
Signed-off-by: Sytse Wielinga <[EMAIL PROTECTED]>
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Shawn Starr <[EMAIL PROTECTED]>

--- linux-2.6.11-rc2/drivers/i2c/chips/lm80.c   2005-01-26 02:04:38.0 
-0500
+++ linux-2.6.11-rc2-fixes/drivers/i2c/chips/lm80.c 2005-01-26 
12:31:26.0 -0500
@@ -99,10 +99,7 @@ static inline long TEMP_FROM_REG(u16 tem
 #define TEMP_LIMIT_TO_REG(val) SENSORS_LIMIT((val)<0?\
((val)-500)/1000:((val)+500)/1000,0,255)
 
-#define ALARMS_FROM_REG(val)   (val)
-
 #define DIV_FROM_REG(val)  (1 << (val))
-#define DIV_TO_REG(val)
((val)==8?3:(val)==4?2:(val)==1?0:1)
 
 /*
  * Client data (each client gets its own)
@@ -269,7 +266,17 @@ static ssize_t set_fan_div(struct device
   DIV_FROM_REG(data->fan_div[nr]));
 
val = simple_strtoul(buf, NULL, 10);
-   data->fan_div[nr] = DIV_TO_REG(val);
+
+   switch (val) {
+   case 1: data->fan_div[nr] = 0; break;
+   case 2: data->fan_div[nr] = 1; break;
+   case 4: data->fan_div[nr] = 2; break;
+   case 8: data->fan_div[nr] = 3; break;
+   default:
+   dev_err(&client->dev, "fan_div value %ld not "
+   "supported. Choose one of 1, 2, 4 or 8!\n", val);
+   return -EINVAL;
+   }
 
reg = (lm80_read_value(client, LM80_REG_FANDIV) & ~(3 << (2 * (nr + 
1
| (data->fan_div[nr] << (2 * (nr + 1)));
@@ -327,7 +334,7 @@ set_temp(os_hyst, temp_os_hyst, LM80_REG
 static ssize_t show_alarms(struct device *dev, char *buf)
 {
struct lm80_data *data = lm80_update_device(dev);
-   return sprintf(buf, "%d\n", ALARMS_FROM_REG(data->alarms));
+   return sprintf(buf, "%u\n", data->alarms);
 }
 
 static DEVICE_ATTR(in0_min, S_IWUSR | S_IRUGO, show_in_min0, set_in_min0);

Re: kbuild: Implicit dependence on the C compiler

[H. Peter Anvin]

Sam Ravnborg wrote:
make KBUILD_NOCMDDEP=1
will do what you want - at least I have it in my tree now.
I could not just ignore 'gcc' - but had to ignore the full commandline.
This is due to more complex commands like:
rm -f file; $(LD) ...
That's probably the right behaviour actually.
Within the Makefile.lib when I check KBUILD_NOCMDDEP there is no
knowledge of the actual command being executed. And an implmentation
that just filtered out $(CC) was too ugly.
And due to the above mentioned command I could not just skip the first
word on the command line.
I will push my bk tree soon and it will show up in next -mm.
It is not perfect in the sense that the last part of the build will get
redone (GEN .version and onwards). This is fixable but not worth it
right now.
So with current implmentation executing:
make
make KBUILD_NOCMDDEP=1 CROSS_COMPILE=i586-pc-linux-gnu-
will result in only a few files being rebuild - and not the whole
kernel as before.
That's fair.  You got what you asked for.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/8] Kconfig: cleanup input menu

[Roman Zippel]

Hi,

On Sat, 29 Jan 2005, Dmitry Torokhov wrote:

> > That's fine, but why is it in the input menu? How do you suggest to make 
> > it selectable without selecting input and without messing the menu 
> > structure?
> 
> Well, probably split input into sections, one of the options would be
> something like "Generic Input Layer" and have evdev, mousedev, etc
> depend on it. serio will not depend on it... nor will gameport as
> I can see someone wanting gameport_raw.

That's not the point of my patch. Feel free to restructure the input menu, 
if you need help you can ask me, but is there any practically relevant 
reason, that serio_raw must not depend on INPUT right now?

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

Re: 2.6.11-rc2-mm2 - "freeing b_committed_data"

[Andrew Morton]

Nathan Lynch <[EMAIL PROTECTED]> wrote:
>
> With both 2.6.11-rc2-mm1 and -mm2 I'm seeing this message occasionally
>  on a ppc64 box with ext3 filesystems:
> 
>  __journal_remove_journal_head: freeing b_committed_data

Yes, that appears to be some mysterious race introduced by Alex's JBD fixes.

>  Is this cause for concern?

It probably introduces journalling inconsistencies such that a well-timed
crash could result in an incorrect recovery, so it's a minor problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.29, e100 and a WOL packet causes keventd going mad

[Marcelo Tosatti]

On Fri, Jan 28, 2005 at 05:48:11PM +0100, Michael Gernoth wrote:
> Hi,
> 
> we have about 70 P4 uniprocessor machines (some with Hyperthreading
> capable CPUs) running linux 2.4.29, which are woken up on the weekdays
> by sending a WOL packet to them. The machines all have a E100 nic with
> WOL enabled in the bios. The E100 driver is compiled into the kernel
> and not loaded as a module.
> 
> If the machine which should be woken up is already running (because
> someone switched it on by hand), the WOL packet causes keventd to go
> mad and "use" 100% CPU:
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 2 root  15   0 000 R 99.9  0.0 140:50.94 keventd

Probably a task event is rescheduling itself repeatedly? e100 does not seem 
to schedule_task() events directly, so I wonder what is going on.

Can you boot a machine with profile=2, then send the WOL packet causing
keventd to go mad and run:

readprofile | sort -nr +2 | head -20

After a few minutes.

Ganesh, Scott, Jeff, any ideas?

> This can be reproduced on any of the 70 machines by simply sending a WOL
> packet to it, when it's already running... No entry is made in the
> kernel log.
> 
> The dmesg of an affected machine can be found at:
> http://wwwcip.informatik.uni-erlangen.de/~simigern/cip-dmesg
> Our kernel-config is at:
> http://wwwcip.informatik.uni-erlangen.de/~simigern/cip-generic-config
> lspci -vvv is at:
> http://wwwcip.informatik.uni-erlangen.de/~simigern/cip-lspci
> 
> We are using a kernel.org linux 2.4.29 kernel patched with the current
> autofs patch and ACL support.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.4] lcd: fix memory leak in lcd_ioctl()

[Marcelo Tosatti]

Applied both, thanks James.

On Thu, Jan 27, 2005 at 06:25:09PM -0600, James Nelson wrote:
> This patch fixes a memory leak in the FLASH_Burn ioctl for the Cobalt LCD 
> interface driver.
> 
> Signed-off-by: James Nelson <[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: 2.6.11-rc2-mm2 - "freeing b_committed_data"

[Nathan Lynch]

Hi-

With both 2.6.11-rc2-mm1 and -mm2 I'm seeing this message occasionally
on a ppc64 box with ext3 filesystems:

__journal_remove_journal_head: freeing b_committed_data

Is this cause for concern?

Nathan


#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-rc2-mm2
# Sat Jan 29 15:32:58 2005
#
CONFIG_64BIT=y
CONFIG_MMU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_FRAME_POINTER=y
CONFIG_FORCE_MAX_ZONEORDER=13

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION="-ntl"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=19
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
# CONFIG_LTT is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_SYSVIPC_COMPAT=y

#
# Platform support
#
# CONFIG_PPC_ISERIES is not set
CONFIG_PPC_MULTIPLATFORM=y
CONFIG_PPC_PSERIES=y
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_MAPLE is not set
CONFIG_PPC=y
CONFIG_PPC64=y
CONFIG_PPC_OF=y
CONFIG_ALTIVEC=y
CONFIG_PPC_SPLPAR=y
CONFIG_IBMVIO=y
# CONFIG_U3_DART is not set
# CONFIG_BOOTX_TEXT is not set
# CONFIG_POWER4_ONLY is not set
# CONFIG_IOMMU_VMERGE is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=128
CONFIG_HMT=y
CONFIG_DISCONTIGMEM=y
CONFIG_NUMA=y
CONFIG_SCHED_SMT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_EEH=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_PPC_RTAS=y
# CONFIG_RTAS_FLASH is not set
CONFIG_SCANLOG=y
CONFIG_LPARCFG=y

#
# General setup
#
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_HOTPLUG_CPU=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PC-card bridges
#

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_SL82C105 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
# CONFIG_PDC202XX_BURST is not

Re: [PATCH 6/8] Kconfig: cleanup input menu

[Dmitry Torokhov]

On Saturday 29 January 2005 18:56, Roman Zippel wrote:
> Hi,
> 
> On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
> 
> > I can assure you that serio_raw driver _does not_ use input system - it is
> > implementation of pre 2.6 /dev/psaux interface giving you access to raw AUX
> > data. It was written so we can still use PS/2 devices for which we don't 
> > have
> > proper in-kernel driver but have working userspace solution. It completely
> > bypasses input layer.
> 
> That's fine, but why is it in the input menu? How do you suggest to make 
> it selectable without selecting input and without messing the menu 
> structure?
> 

Well, probably split input into sections, one of the options would be
something like "Generic Input Layer" and have evdev, mousedev, etc
depend on it. serio will not depend on it... nor will gameport as
I can see someone wanting gameport_raw.

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

[PATCH] LTT config bits break config tree

[Matt Mackall]

The LTT option got dropped in the middle of the CONFIG_EMBEDDED menu
without a dependency on EMBEDDED. Selecting EMBEDDED in menuconfig now
causes a bunch of random embedded options to appear on the general
options menu.

Not really sure if this belongs here or in the debugging menus.

Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>

Index: tq/init/Kconfig
===
--- tq.orig/init/Kconfig2005-01-29 16:17:03.0 -0800
+++ tq/init/Kconfig 2005-01-29 16:23:34.0 -0800
@@ -324,7 +324,7 @@
 config LTT
bool "Linux Trace Toolkit support"
select RELAYFS_FS
-   depends on !X86_64
+   depends on !X86_64 && EMBEDDED
default n
---help---
  It is possible for the kernel to log important events to a trace


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

[PATCH] Fix SERIAL_TXX9 dependencies

[Ralf Baechle]

Ask for SERIAL_TXX9 only on those devices that actually have one.

 arch/mips/Kconfig  |2 ++
 drivers/serial/Kconfig |6 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

Index: linux-2.6.11-rc2/drivers/serial/Kconfig
===
--- linux-2.6.11-rc2.orig/drivers/serial/Kconfig2005-01-29 
03:18:00.0 +0100
+++ linux-2.6.11-rc2/drivers/serial/Kconfig 2005-01-30 01:10:46.426853785 
+0100
@@ -794,8 +794,12 @@
 
 config SERIAL_TXX9
bool "TMPTX39XX/49XX SIO support"
-   depends on MIPS || PCI
+   depends HAS_TXX9_SERIAL
select SERIAL_CORE
+   default y
+
+config HAS_TXX9_SERIAL
+   bool
 
 config SERIAL_TXX9_CONSOLE
bool "TMPTX39XX/49XX SIO Console support"
Index: linux-2.6.11-rc2/arch/mips/Kconfig
===
--- linux-2.6.11-rc2.orig/arch/mips/Kconfig 2005-01-30 00:45:48.808734334 
+0100
+++ linux-2.6.11-rc2/arch/mips/Kconfig  2005-01-30 01:00:55.533811631 +0100
@@ -848,6 +848,7 @@
bool "Support for Toshiba TBTX49[23]7 board"
depends on MIPS32
select DMA_NONCOHERENT
+   select HAS_TXX9_SERIAL
select HW_HAS_PCI
select I8259
select ISA
@@ -970,6 +971,7 @@
 config MIPS_TX3927
bool
depends on TOSHIBA_JMR3927
+   select HAS_TXX9_SERIAL
default y
 
 config PCI_MARVELL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] OpenBSD Networking-related randomization port

[Horst von Brand]

Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
 =?ISO-8859-1?Q?Garc=EDa-Hierro?= <[EMAIL PROTECTED]> said:
> Attached you can find a split up patch ported from grSecurity [1], as
> Linus commented that he wouldn't get a whole-sale patch, I was working
> on it and also studying what features of grSecurity can be implemented
> without a development or maintenance overhead, aka less-invasive
> implementations.

OK.

> It adds support for advanced networking-related randomization, in
> concrete it adds support for TCP ISNs randomization,

1.

>  RPC XIDs
> randomization,

2.

>IP IDs randomization

3.

> and finally a sub-key under the
> Cryptographic options menu for Linux PRNG [2] enhancements

4.   (useful now
> and also for future patch submissions), which currently has an only-one
> option for poll sizes increasing (x2).

5 (it seems).

Needs way more splitting?

> As it's impact is minimal (in performance and development/maintenance
> terms), I recommend to merge it, as it gives a basic prevention for the
> so-called system fingerprinting (which is used most by "kids" to know
> how old and insecure could be a target system, many time used as the
> first, even only-one, data to decide if attack or not the target host)
> among other things.

How does it prevent fingerprinting?

And a huge, compressed patch attached.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] micro optimization in kernel/params.c; don't call to_module_kobject before we really have to.

[Brian Gerst]

Jesper Juhl wrote:
In kernel/params.c::module_attr_show and 
kernel/params.c::module_attr_store we call to_module_kobject() and save 
the result in a local variable right before a conditional statement that 
does not depend on the call to to_module_kobject() and may cause the 
function to return. If the function returns before we use the result of 
to_module_kobject() then the call is just a waste of time. 
The patch moves the call to to_module_kobject() down just before it is 
actually used, thus we save a call to the function in a few cases. I doubt 
this is in any way measurable, but I see no reason to not move the call - 
it should be an infinitesimal improvement with no ill sideeffects.
Please consider applying.

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -up linux-2.6.11-rc2-bk7-orig/kernel/params.c linux-2.6.11-rc2-bk7/kernel/params.c
--- linux-2.6.11-rc2-bk7-orig/kernel/params.c	2005-01-29 23:54:53.0 +0100
+++ linux-2.6.11-rc2-bk7/kernel/params.c	2005-01-30 00:27:08.0 +0100
@@ -625,11 +625,12 @@ static ssize_t module_attr_show(struct k
 	int ret;
 
 	attribute = to_module_attr(attr);
-	mk = to_module_kobject(kobj);
 
 	if (!attribute->show)
 		return -EPERM;
 
+	mk = to_module_kobject(kobj);
+
 	if (!try_module_get(mk->mod))
 		return -ENODEV;
 
@@ -649,11 +650,12 @@ static ssize_t module_attr_store(struct 
 	int ret;
 
 	attribute = to_module_attr(attr);
-	mk = to_module_kobject(kobj);
 
 	if (!attribute->store)
 		return -EPERM;
 
+	mk = to_module_kobject(kobj);
+
 	if (!try_module_get(mk->mod))
 		return -ENODEV;
 


I'd bet that the compiler already reorders the assignment since there is 
no side effect to to_module_kobject().  Even with a patch like this you 
can't control exactly when the assignment is done.  There may not even 
be an assignment, since mk is a constant offset of kobj.

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

Re: CONFIG_THERM_PM72 is missing from .config from recent kernels (2.6.10, 2.6.11)

[Randy.Dunlap]

Maurice Volaski wrote:
CONFIG_THERM_PM72 is required for thermal management in at least Macs, 
most notably the PowerMac G5. Without it, the computer will run its fans 
at the max and is very loud.

It's missing from .config in at least a few releases of recent kernels 
(2.6.10, 2.6.11).

Does anyone know why?
Did you enable/select it?
It's not on by default (in 2.6.11-rc2).
First you need to enable this one:
config I2C_KEYWEST
tristate "Powermac Keywest I2C interface"
depends on I2C && PPC_PMAC
and then this one:
config THERM_PM72
tristate "Support for thermal management on PowerMac G5"
depends on I2C && I2C_KEYWEST && PPC_PMAC64
--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/04] Add LRW

[Matt Mackall]

On Mon, Jan 24, 2005 at 12:57:50PM +0100, Fruhwirth Clemens wrote:
> This is the core of my LRW patch. Added test vectors.
> http://grouper.ieee.org/groups/1619/email/pdf00017.pdf

Please include a URL for the standard at the top of the LRW code and
next to the test vectors. I had to search around a fair bit for decent
background material, would be helpful to a couple other references as
well.

> +static inline void findAlignment(u128 callersN, int value, int *align) {
> + int i;

Your gfmulseq code has lots of StudlyCaps and strange whitespace, eg
this '{' should be on the next line.

> + /* Copy N, so lsr does not destroy caller's copy */
> + u128_alloc(N);
> + copy128(N,callersN);

The usage of your u128 type is really confusing, so 'u128' is an
especially bad name. I expect u128 to work like u64 and u32. I propose
gf128_t.

> + int i;  // Outer control loop counter

C++ comments.

> +#define min(a,b) (a)<(b)?(a):(b)

Have a very nice one of those already.

> +#ifdef DEBUG
> + printf("negative step at:");
> + print128(currentN);
> +#endif

Better to use printk and put #define printk printf in your userspace
test harness.

> +typedef u64 *u128;
> +typedef u64 *u128_t;

Did I mention confusing?

> +#define u128_alloc(VAR) u64 _ ## VAR ## _[2]; u128 VAR = _ ## VAR ## _

Wrap this in a struct, please. That's disgusting.

> -obj-$(CONFIG_CRYPTO) += api.o scatterwalk.o cipher.o digest.o compress.o \
> +obj-$(CONFIG_CRYPTO) += api.o scatterwalk.o cipher.o digest.o compress.o 
> lrw.o gfmulseq.o \

LRW and the GF(2**128) code is not configurable?

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

Re: 2.4.29, e100 and a WOL packet causes keventd going mad

[Bukie Mabayoje]

Michael Gernoth wrote:

> On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
> > Do you know the official NIC product name e.g Pro/100B. I need to identify
> > the LAN Controller. There are differences between  557 (not sure if 557 can
> > do WOL), 558 and 559 how they ASSERT the PME# signal. Even the same chip 
> > have
> > differences between steppings.
>
> The chip is integrated on the motherboard. Its PCI ID is 8086:1039.
> lspci says: Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller (rev 81)
> If you want I can open up one of these machines tomorrow to look on the chip
> directly.
>
> Regards,
>   Michael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I can't  find the datasheet for 82801BD. 82801 are typically I/O Controller 
Hub.  I need to see how it drives the  PCI Interface Signals.

I will try an reproduce it on a different set of chipset. Basically send a WOL 
packet to a live linux system. And see if keventd consumes excessive CPU time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6/8] Kconfig: cleanup input menu

[Roman Zippel]

Hi,

On Sat, 29 Jan 2005, Dmitry Torokhov wrote:

> I can assure you that serio_raw driver _does not_ use input system - it is
> implementation of pre 2.6 /dev/psaux interface giving you access to raw AUX
> data. It was written so we can still use PS/2 devices for which we don't have
> proper in-kernel driver but have working userspace solution. It completely
> bypasses input layer.

That's fine, but why is it in the input menu? How do you suggest to make 
it selectable without selecting input and without messing the menu 
structure?

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

Re: 2.6.11-rc2-mm2

[Sean Neakums]

Sean Neakums <[EMAIL PROTECTED]> writes:

> On a PowerBook (PowerBook5.4), when snd_powermac is modprobed during
> the boot, I get the following.  After similar messages for a few more
> modules, the machine seems wedged.

Brice Goglin's patch fixes this.

However, when I modprobe radeonfb I get:

Jan 29 23:38:16 briny kernel: PCI: Unable to reserve mem region #1:[EMAIL 
PROTECTED] for device :00:10.0
Jan 29 23:38:16 briny kernel: radeonfb: probe of :00:10.0 failed with error 
-16

Not sure if this is expected or not on this platform.

With radeonfb built-in (my current working configuration with 2.6.9)
the screen clears and the machine seems to hang early in the boot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/cdrom/isp16.c: small cleanups

[Bartlomiej Zolnierkiewicz]

On Sun, 30 Jan 2005 00:46:24 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 29, 2005 at 06:51:25PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Sat, 29 Jan 2005 18:11:08 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > This patch makes the needlessly global function isp16_init static.
> > >
> > > As a result, it turned out that both this function and some other code
> > > are only required #ifdef MODULE.
> >
> > Your patch is correct but it is wrong. ;)
> >
> > #ifdefs around isp16_init() need to be removed as
> > otherwise this driver is not initialized in built-in case.
> 
> It's somehow initialized via isp16_setup.

Could you explain?

AFAICS isp16_setup() only handles "isp16=" boot parameter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/cdrom/isp16.c: small cleanups

[Adrian Bunk]

On Sat, Jan 29, 2005 at 06:51:25PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> On Sat, 29 Jan 2005 18:11:08 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > This patch makes the needlessly global function isp16_init static.
> > 
> > As a result, it turned out that both this function and some other code
> > are only required #ifdef MODULE.
> 
> Your patch is correct but it is wrong. ;)
> 
> #ifdefs around isp16_init() need to be removed as
> otherwise this driver is not initialized in built-in case.

It's somehow initialized via isp16_setup.

> Bartlomiej

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/

[PATCH] micro optimization in kernel/params.c; don't call to_module_kobject before we really have to.

[Jesper Juhl]

In kernel/params.c::module_attr_show and 
kernel/params.c::module_attr_store we call to_module_kobject() and save 
the result in a local variable right before a conditional statement that 
does not depend on the call to to_module_kobject() and may cause the 
function to return. If the function returns before we use the result of 
to_module_kobject() then the call is just a waste of time. 
The patch moves the call to to_module_kobject() down just before it is 
actually used, thus we save a call to the function in a few cases. I doubt 
this is in any way measurable, but I see no reason to not move the call - 
it should be an infinitesimal improvement with no ill sideeffects.
Please consider applying.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

diff -up linux-2.6.11-rc2-bk7-orig/kernel/params.c 
linux-2.6.11-rc2-bk7/kernel/params.c
--- linux-2.6.11-rc2-bk7-orig/kernel/params.c   2005-01-29 23:54:53.0 
+0100
+++ linux-2.6.11-rc2-bk7/kernel/params.c2005-01-30 00:27:08.0 
+0100
@@ -625,11 +625,12 @@ static ssize_t module_attr_show(struct k
int ret;
 
attribute = to_module_attr(attr);
-   mk = to_module_kobject(kobj);
 
if (!attribute->show)
return -EPERM;
 
+   mk = to_module_kobject(kobj);
+
if (!try_module_get(mk->mod))
return -ENODEV;
 
@@ -649,11 +650,12 @@ static ssize_t module_attr_store(struct 
int ret;
 
attribute = to_module_attr(attr);
-   mk = to_module_kobject(kobj);
 
if (!attribute->store)
return -EPERM;
 
+   mk = to_module_kobject(kobj);
+
if (!try_module_get(mk->mod))
return -ENODEV;
 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6/8] Kconfig: cleanup input menu

[Dmitry Torokhov]

On Saturday 29 January 2005 18:20, Roman Zippel wrote:
> Hi,
> 
> On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
> 
> > On Saturday 29 January 2005 17:20, Roman Zippel wrote:
> > > --- linux-2.6.11.orig/drivers/input/serio/KconfigÂÂÂ2005-01-29 
> > > 22:50:43.404946203 +0100
> > > +++ linux-2.6.11/drivers/input/serio/Kconfig2005-01-29 
> > > 22:56:42.549085439 +0100
> > > @@ -3,6 +3,7 @@
> > > Â#
> > > Âconfig SERIO
> > > tristate "Serial i/o support" if EMBEDDED || !X86
> > > +ÂÂÂdepends on INPUT
> > 
> > 
> > 
> > serio_raw works fine without INPUT.
> 
> All current serio users depend on INPUT, it's maybe not a strict 
> dependency, but it pretty much needs INPUT anyway to be usable, so I don't 
> see the problem.
> The alternative is to move it completely out of the input menu, if it's 
> really that important for the user being able to select it without input.
> 

I can assure you that serio_raw driver _does not_ use input system - it is
implementation of pre 2.6 /dev/psaux interface giving you access to raw AUX
data. It was written so we can still use PS/2 devices for which we don't have
proper in-kernel driver but have working userspace solution. It completely
bypasses input layer.
 
-- 
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: [gentoo-ppc-dev] CONFIG_THERM_PM72 is missing from .config from recent kernels (2.6.10, 2.6.11)

[Maurice Volaski]

Hello Maurice
 It's missing from .config in at least a few releases of recent
 kernels (2.6.10, 2.6.11).
Definitly not true, at least for ppc32.
Note that..
1) I looked only at official kernel source code
and
2) I looked only at a few releases, not every patchset.
and
3) I looked only at the resulting .config file after preparing it 
with make menuconfig.

Linux g5 2.6.10-gentoo-r6-g5 #6 SMP Wed Jan 26 23:05:05 CET 2005 ppc
PPC970, altivec supported PowerMac7,2 GNU/Linux
From what I can tell, the .config file is built up from different 
files. I just looked at gentoo-dev-sources for this version and it 
is, in fact, present for ppc64 in
/usr/src/linux-2.6.10-gentoo-r6/arch/ppc64/defconfig

That suggests the mechanism that generates the .config files is not 
working right under certain circumstances related to the 64bit G5.
--

Maurice Volaski, [EMAIL PROTECTED]
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CONFIG_THERM_PM72 is missing from .config from recent kernels (2.6.10, 2.6.11)

[Maurice Volaski]

CONFIG_THERM_PM72 is required for thermal management in at least 
Macs, most notably the PowerMac G5. Without it, the computer will run 
its fans at the max and is very loud.

It's missing from .config in at least a few releases of recent 
kernels (2.6.10, 2.6.11).

Does anyone know why?
--
Maurice Volaski, [EMAIL PROTECTED]
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Possible bug in keyboard.c (2.6.10)

[Dmitry Torokhov]

On Saturday 29 January 2005 06:25, Vojtech Pavlik wrote:
> On Sat, Jan 29, 2005 at 04:50:55AM +, Al Viro wrote:
> 
> > > I'm very sorry about the locking, but the thing grew up in times of
> > > kernel 2.0, which didn't require any locking. There are a few possible
> > 
> > Incorrect.  You have blocking allocations in critical areas and they
> > required locking all way back.
> 
> Ok. I see a problem where input_register_device() calls input handler
> connect methods, which do kmalloc(). This would be bad even on 2.0.
> 
> Anything else? I believe the ->open()/->release() methods are still
> protected.
> 

evdev, tsdev, mousedev, joydev need to protect their client lists because
interrupt could try to deliver event to already deleted device (client)
.
> > > races with device registration/unregistration, and it's on my list to
> > > fix that, however under normal operation there shouldn't be any need for
> > > locks, as there are no complex structures built that'd become
> > > inconsistent. 
> > 
> > Um-hm...  Vojtech, meet USB mouse; USB mouse, meet Vojtech.  Now watch
> > a disconnect and reconnect happening when luser suddenly gets overexcited
> > and jerks the wrong hand a bit too hard while browsing the most profitable
> > sort of website...
> 
> I know. As I said, this is a problem I know about, and will be fixed. I
> was mainly interested whether anyone sees further problems in scenarios
> which don't include device addition/removal.
> 
> We already fixed this in serio, and input and gameport are next in the
> list.
>

For the record I am still working on gameport conversion, just did not have
enough time lately...
 
> > > If you find scenarios which will lead to trouble in the event delivery
> > > system, please tell me, and I'll try to fix that as soon as possible.
> > 
> > See above.  Devices appearing and disappearing *are* normal.  
> 

-- 
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: Possible bug in keyboard.c (2.6.10)

[Dmitry Torokhov]

On Saturday 29 January 2005 06:12, Vojtech Pavlik wrote:
> However, on 2.6, where you can have more than one keyboard, it'd be
> better to use the EVIOCSKEYCODE ioctl on the event device instead of the
> KDSKEYCODE ioctl on the console, as the later only changes the first
> found keyboard.
> 

FWIW I changed atkbd so every keyboard has separate keymap (so one can set
one keyboard to set 2 and other to set 3). I think it should be possible to
adjust keymaps on individual keyboards to accurately map keys when keyboards
are different.

-- 
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: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement -

[Greg KH]

On Thu, Jan 27, 2005 at 11:56:46AM -0500, Shawn Starr wrote:
> Description: Cleanup some cluttered macros, add error
> checking for fan divisor value set.

Hm, we'll get there yet.  Your patch was not in a plain text form, so
that I could apply it directly from the email.

> Approved-by: Greg KH <[EMAIL PROTECTED]>

I have not "approved it" yet at all.

> Signed-off-by: Sytse Wielinga
> <[EMAIL PROTECTED]>
> Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
> Signed-off-by: Shawn Starr <[EMAIL PROTECTED]>

You have line wrap here too :(

>  --- Greg KH <[EMAIL PROTECTED]> wrote: 
> > On Wed, Jan 26, 2005 at 12:31:30PM -0500, Shawn
> > Starr wrote:
> > > Here is the corrected fix, yeah that didn't make
> > > sense.   
> > > 3AM isn't a good time to send patches I guess :-)
> > 
> > Care to resend it, with a full description and a
> > Signed-off-by: line so
> > I can apply it?
> > 
> > thanks,
> > 
> > greg k-h
> >  

What's this "bottom post" stuff in here?

Also, please CC: the sensors mailing list so the developers there can
review the changes.

Can you try it again from scratch?

thanks,

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

Re: [patch 2.6.11-rc2-mm2] fix SERIAL_TXX9 dependencies

[Ralf Baechle]

On Sun, Jan 30, 2005 at 12:12:55AM +0100, Adrian Bunk wrote:

> > Changes since 2.6.11-rc2-mm1:
> >...
> > +mips-txx9-serieal-driver-rewrite.patch
> >...
> >  MIPS update
> >...
> 
> It seems the SERIAL_TXX9 dependencies are incorrect.

Wrong also.  Will fix in a minute.

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

Re: [PATCH 6/8] Kconfig: cleanup input menu

[Roman Zippel]

Hi,

On Sat, 29 Jan 2005, Dmitry Torokhov wrote:

> On Saturday 29 January 2005 17:20, Roman Zippel wrote:
> > --- linux-2.6.11.orig/drivers/input/serio/Kconfig   2005-01-29 
> > 22:50:43.404946203 +0100
> > +++ linux-2.6.11/drivers/input/serio/Kconfig2005-01-29 
> > 22:56:42.549085439 +0100
> > @@ -3,6 +3,7 @@
> >  #
> >  config SERIO
> > tristate "Serial i/o support" if EMBEDDED || !X86
> > +   depends on INPUT
> 
> 
> 
> serio_raw works fine without INPUT.

All current serio users depend on INPUT, it's maybe not a strict 
dependency, but it pretty much needs INPUT anyway to be usable, so I don't 
see the problem.
The alternative is to move it completely out of the input menu, if it's 
really that important for the user being able to select it without input.

bye, Roman

Re: i8042 access timings

[Dmitry Torokhov]

On Saturday 29 January 2005 14:59, Jaco Kroon wrote:
> > Compiling USB 1.1 support does the very same thing as specifying
> > usb-handoff on the command like - tells the BIOS to keep its hands off
> > the USB _and_ PS/2 controllers.
> 
> I'm missing something, I have USB1.1 compiled in, then why does the 
> touchpad not work if it does the very same thing as usb-handoff?

USB initializes very late, after i8042 and psmouse has already run
their probes. So unless there is "usb-handoff" psmouse talks to a fake
BIOS-emulated mouse, not a real touchpad. 

-- 
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: DRI (was Re: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*)

[Dave Airlie]

> 
> No, XAA is normally used for 2D acceleration.  This is hardware
> accelerated but doesn't use DRI, X does 2D accel by talking directly to
> the hardware without the kernel's involvement.
> 
well not totally true, X on radeon/r200/r300 cards needs the DRM to
load the microcode for the command processor, this enables some major
speedups in the 2D code (it still talk direct to the card, but needs
the CP loading...) but X runs as root so it has no worries opening the
device...

the issue is with using having the perms set to 0660 since the drm
started supporting sysfs and udev... normally X created the dri
devices and set the permissions to what was in the X config, normally
666 or 660 with a dri group...

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/

[patch 2.6.11-rc2-mm2] fix SERIAL_TXX9 dependencies

[Adrian Bunk]

On Sat, Jan 29, 2005 at 01:11:34PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc2-mm1:
>...
> +mips-txx9-serieal-driver-rewrite.patch
>...
>  MIPS update
>...

It seems the SERIAL_TXX9 dependencies are incorrect.

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

--- linux-2.6.11-rc2-mm2-full/drivers/serial/Kconfig.old2005-01-30 
00:08:24.0 +0100
+++ linux-2.6.11-rc2-mm2-full/drivers/serial/Kconfig2005-01-30 
00:07:48.0 +0100
@@ -794,7 +794,7 @@
 
 config SERIAL_TXX9
bool "TMPTX39XX/49XX SIO support"
-   depends on MIPS || PCI
+   depends on MIPS && PCI
select SERIAL_CORE
 
 config SERIAL_TXX9_CONSOLE

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

Re: 2.6.11-rc2-mm2

[Sean Neakums]

On a PowerBook (PowerBook5.4), when snd_powermac is modprobed during
the boot, I get the following.  After similar messages for a few more
modules, the machine seems wedged.

Reversed bk-driver-core.patch and rebuilt, same result.


kobject_register failed for snd_page_alloc (-17)
Call Trace:
  dump_stack
  kobject_register
  mod_sysfs_setup
  load_module
  sys_init_module
  ret_from_syscall
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc2-mm2

[Brice Goglin]

Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm2/
Changes since 2.6.11-rc2-mm1:
+fix-kallsyms-insmod-rmmod-race.patch
+fix-kallsyms-insmod-rmmod-race-fix.patch
+fix-kallsyms-insmod-rmmod-race-fix-fix.patch
 fix a modules race
Hi Andrew,
CONFIG_STOP_MACHINE is not defined on my laptop. This breaks module loading.
The reason is that stop_machine_run does nothing, especially
it does not call the function that is passed as a parameter.
Looks like -fix needs another fix :)
What about a patch like this one ?
Regards,
Brice
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
--- linux-mm/include/linux/stop_machine.h.orig  2005-01-29 23:37:11.0 
+0100
+++ linux-mm/include/linux/stop_machine.h   2005-01-29 23:37:31.0 
+0100
@@ -57,7 +57,7 @@
 static inline int stop_machine_run(int (*fn)(void *), void *data,
   unsigned int cpu)
 {
-   return 0;
+   return fn(data);
 }
 #endif /* CONFIG_STOP_MACHINE */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6/8] Kconfig: cleanup input menu

[Dmitry Torokhov]

On Saturday 29 January 2005 17:20, Roman Zippel wrote:
> --- linux-2.6.11.orig/drivers/input/serio/Kconfig   2005-01-29 
> 22:50:43.404946203 +0100
> +++ linux-2.6.11/drivers/input/serio/Kconfig2005-01-29 22:56:42.549085439 
> +0100
> @@ -3,6 +3,7 @@
>  #
>  config SERIO
> tristate "Serial i/o support" if EMBEDDED || !X86
> +   depends on INPUT



serio_raw works fine without INPUT.

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

2.6.11-rc2-{mm2,bk7} does not compile with UML

[Zoltan NAGY]

Hello!
Here is the error:
[EMAIL PROTECTED]:~/uml/linux$ ARCH=um make vmlinux
...
gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing 
-fno-common -ffreestanding -O2 -fno-omit-frame-pointer -g -U__i386__ 
-Ui386 -D__arch_um__ -DSUBARCH=\"i386\" -Iarch/um/include  
-I/home/nagyz/uml/linux/arch/um/kernel/skas/include -D_GNU_SOURCE 
-D_LARGEFILE64_SOURCE  -c -o arch/um/kernel/process.o 
arch/um/kernel/process.c
arch/um/kernel/process.c: In function `check_ptrace':
arch/um/kernel/process.c:321: error: `PTRACE_SETOPTIONS' undeclared 
(first use in this function)
arch/um/kernel/process.c:321: error: (Each undeclared identifier is 
reported only once
arch/um/kernel/process.c:321: error: for each function it appears in.)
arch/um/kernel/process.c:321: error: `PTRACE_O_TRACESYSGOOD' undeclared 
(first use in this function)
make[1]: *** [arch/um/kernel/process.o] Error 1
make: *** [arch/um/kernel] Error 2
[EMAIL PROTECTED]:~/uml/linux$

any ideas?
Regards,
--
Zoltan NAGY,
Software Engineer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 6/8] Kconfig: cleanup input menu

[Roman Zippel]

This properly indents the input menu.
Move SOUND_GAMEPORT to its user, so it's easier to set it to y, even if 
GAMEPORT is n.

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 drivers/input/Kconfig  |3 +++
 drivers/input/gameport/Kconfig |   21 +
 drivers/input/serio/Kconfig|3 ++-
 sound/oss/Kconfig  |   22 ++
 4 files changed, 28 insertions(+), 21 deletions(-)

Index: linux-2.6.11/sound/oss/Kconfig
===
--- linux-2.6.11.orig/sound/oss/Kconfig 2005-01-29 22:50:43.404946203 +0100
+++ linux-2.6.11/sound/oss/Kconfig  2005-01-29 22:56:42.549085439 +0100
@@ -3,6 +3,28 @@
 # 18 Apr 1998, Michael Elizabeth Chastain, 
 # More hacking for modularisation.
 #
+
+# Yes, SOUND_GAMEPORT looks a bit odd. Yes, it ends up being turned on
+# in every .config. Please don't touch it. It is here to handle an
+# unusual dependency between GAMEPORT and sound drivers.
+#
+# Some sound drivers call gameport functions. If GAMEPORT is
+# not selected, empty stubs are provided for the functions and all is
+# well.
+# If GAMEPORT is built in, everything is fine.
+# If GAMEPORT is a module, however, it would need to be loaded for the
+# sound driver to be able to link properly. Therefore, the sound
+# driver must be a module as well in that case. Since there's no way
+# to express that directly in Kconfig, we use SOUND_GAMEPORT to
+# express it. SOUND_GAMEPORT boils down to "if GAMEPORT is 'm',
+# anything that depends on SOUND_GAMEPORT must be 'm' as well. if
+# GAMEPORT is 'y' or 'n', it can be anything".
+config SOUND_GAMEPORT
+   tristate
+   depends on SOUND_PRIME
+   default m if GAMEPORT=m
+   default y
+
 # Prompt user for primary drivers.
 config SOUND_BT878
tristate "BT878 audio dma"
Index: linux-2.6.11/drivers/input/serio/Kconfig
===
--- linux-2.6.11.orig/drivers/input/serio/Kconfig   2005-01-29 
22:50:43.404946203 +0100
+++ linux-2.6.11/drivers/input/serio/Kconfig2005-01-29 22:56:42.549085439 
+0100
@@ -3,6 +3,7 @@
 #
 config SERIO
tristate "Serial i/o support" if EMBEDDED || !X86
+   depends on INPUT
default y
---help---
  Say Yes here if you have any input device that uses serial I/O to
@@ -19,7 +20,7 @@ config SERIO
 config SERIO_I8042
tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
default y
-   select SERIO
+   depends on SERIO
depends on !PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && !M68K
---help---
  i8042 is the chip over which the standard AT keyboard and PS/2
Index: linux-2.6.11/drivers/input/gameport/Kconfig
===
--- linux-2.6.11.orig/drivers/input/gameport/Kconfig2005-01-29 
22:50:43.404946203 +0100
+++ linux-2.6.11/drivers/input/gameport/Kconfig 2005-01-29 22:56:42.549085439 
+0100
@@ -3,6 +3,7 @@
 #
 config GAMEPORT
tristate "Gameport support"
+   depends on INPUT
---help---
  Gameport support is for the standard 15-pin PC gameport. If you
  have a joystick, gamepad, gameport card, a soundcard with a gameport
@@ -20,26 +21,6 @@ config GAMEPORT
  module will be called gameport.
 
 
-# Yes, SOUND_GAMEPORT looks a bit odd. Yes, it ends up being turned on
-# in every .config. Please don't touch it. It is here to handle an
-# unusual dependency between GAMEPORT and sound drivers.
-#
-# Some sound drivers call gameport functions. If GAMEPORT is
-# not selected, empty stubs are provided for the functions and all is
-# well.
-# If GAMEPORT is built in, everything is fine.
-# If GAMEPORT is a module, however, it would need to be loaded for the
-# sound driver to be able to link properly. Therefore, the sound
-# driver must be a module as well in that case. Since there's no way
-# to express that directly in Kconfig, we use SOUND_GAMEPORT to
-# express it. SOUND_GAMEPORT boils down to "if GAMEPORT is 'm',
-# anything that depends on SOUND_GAMEPORT must be 'm' as well. if
-# GAMEPORT is 'y' or 'n', it can be anything".
-config SOUND_GAMEPORT
-   tristate
-   default y if GAMEPORT!=m
-   default m if GAMEPORT=m
-
 config GAMEPORT_NS558
tristate "Classic ISA and PnP gameport support"
depends on GAMEPORT
Index: linux-2.6.11/drivers/input/Kconfig
===
--- linux-2.6.11.orig/drivers/input/Kconfig 2005-01-29 22:50:43.404946203 
+0100
+++ linux-2.6.11/drivers/input/Kconfig  2005-01-29 22:56:42.549085439 +0100
@@ -23,6 +23,7 @@ config INPUT
  module will be called input.
 
 comment "Userland interfaces"
+   depends on INPUT
 
 config INPUT_MOUSEDEV
tristate "Mouse interface" if EMBEDDED
@@ -135,12 +136,14 @@ config INPUT_EVBUG
  module

[PATCH 5/8] Kconfig: cleanup various driver menus

[Roman Zippel]

This properly indents various driver menus.
Remove PARPORT_PC_CML1.

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 mtd/Kconfig |   18 +-
 parport/Kconfig |   12 +++-
 video/Kconfig   |   29 ++---
 3 files changed, 26 insertions(+), 33 deletions(-)

Index: linux-2.6.11/drivers/parport/Kconfig
===
--- linux-2.6.11.orig/drivers/parport/Kconfig   2005-01-29 22:50:43.242974099 
+0100
+++ linux-2.6.11/drivers/parport/Kconfig2005-01-29 22:55:31.785275067 
+0100
@@ -46,15 +46,9 @@ config PARPORT_PC
 
  If unsure, say Y.
 
-config PARPORT_PC_CML1
-   tristate
-   depends on PARPORT!=n && PARPORT_PC!=n
-   default PARPORT_PC if SERIAL_8250=y
-   default m if SERIAL_8250=m
-
 config PARPORT_SERIAL
tristate "Multi-IO cards (parallel and serial)"
-   depends on SERIAL_8250!=n && PARPORT_PC_CML1 && PCI
+   depends on SERIAL_8250 && PARPORT_PC && PCI
help
  This adds support for multi-IO PCI cards that have parallel and
  serial ports.  You should say Y or M here.  If you say M, the module
@@ -118,8 +112,8 @@ config PARPORT_ATARI
 
 config PARPORT_GSC
tristate
-   depends on GSC
-   default PARPORT
+   default GSC
+   depends on PARPORT
 
 config PARPORT_SUNBPP
tristate "Sparc hardware (EXPERIMENTAL)"
Index: linux-2.6.11/drivers/mtd/Kconfig
===
--- linux-2.6.11.orig/drivers/mtd/Kconfig   2005-01-29 22:50:43.242974099 
+0100
+++ linux-2.6.11/drivers/mtd/Kconfig2005-01-29 22:55:31.786274895 +0100
@@ -27,6 +27,15 @@ config MTD_DEBUG_VERBOSE
help
  Determines the verbosity level of the MTD debugging messages.
 
+config MTD_CONCAT
+   tristate "MTD concatenating support"
+   depends on MTD
+   help
+ Support for concatenating several MTD devices into a single
+ (virtual) one. This allows you to have -for example- a JFFS(2)
+ file system spanning multiple physical flash chips. If unsure,
+ say 'Y'.
+
 config MTD_PARTITIONS
bool "MTD partitioning support"
depends on MTD
@@ -40,15 +49,6 @@ config MTD_PARTITIONS
  devices. Partitioning on NFTL 'devices' is a different - that's the
  'normal' form of partitioning used on a block device.
 
-config MTD_CONCAT
-   tristate "MTD concatenating support"
-   depends on MTD
-   help
- Support for concatenating several MTD devices into a single
- (virtual) one. This allows you to have -for example- a JFFS(2)
- file system spanning multiple physical flash chips. If unsure,
- say 'Y'.
-
 config MTD_REDBOOT_PARTS
tristate "RedBoot partition table parsing"
depends on MTD_PARTITIONS
Index: linux-2.6.11/drivers/video/Kconfig
===
--- linux-2.6.11.orig/drivers/video/Kconfig 2005-01-29 22:50:43.242974099 
+0100
+++ linux-2.6.11/drivers/video/Kconfig  2005-01-29 22:55:31.787274723 +0100
@@ -1062,7 +1062,7 @@ config FB_G364
 
 config FB_68328
bool "Motorola 68328 native frame buffer support"
-   depends on (M68328 || M68EZ328 || M68VZ328)
+   depends on FB && (M68328 || M68EZ328 || M68VZ328)
help
  Say Y here if you want to support the built-in frame buffer of
  the Motorola 68328 CPU family.
@@ -1081,22 +1081,8 @@ config FB_PXA
 
  If unsure, say N.
 
-config FB_W100
-   tristate "W100 frame buffer support"
-   depends on FB && PXA_SHARPSL
-   ---help---
- Frame buffer driver for the w100 as found on the Sharp SL-Cxx series.
-
- This driver is also available as a module ( = code which can be
- inserted and removed from the running kernel whenever you want). The
- module will be called vfb. If you want to compile it as a module,
- say M here and read .
-
- If unsure, say N.
-
 config FB_PXA_PARAMETERS
bool "PXA LCD command line parameters"
-   default n
depends on FB_PXA
---help---
  Enable the use of kernel command line or module parameters
@@ -,6 +1097,19 @@ config FB_PXA_PARAMETERS
 
   describes the available parameters.
 
+config FB_W100
+   tristate "W100 frame buffer support"
+   depends on FB && PXA_SHARPSL
+   ---help---
+ Frame buffer driver for the w100 as found on the Sharp SL-Cxx series.
+
+ This driver is also available as a module ( = code which can be
+ inserted and removed from the running kernel whenever you want). The
+ module will be called vfb. If you want to compile it as a module,
+ say M here and read .
+
+ If unsure, say N.
+
 config FB_VIRTUAL
tristate "Virtual Frame Buffer support (ONLY FOR TESTING!)"
depends on FB
-
To unsubscribe fr

[PATCH 8/8] Kconfig: cleanup USB menu

[Roman Zippel]

This properly indents the USB menu.

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 Kconfig |   18 ++
 host/Kconfig|   18 --
 storage/Kconfig |1 +
 3 files changed, 19 insertions(+), 18 deletions(-)

Index: linux-2.6.11/drivers/usb/host/Kconfig
===
--- linux-2.6.11.orig/drivers/usb/host/Kconfig  2005-01-29 22:50:43.297964628 
+0100
+++ linux-2.6.11/drivers/usb/host/Kconfig   2005-01-29 22:56:58.568325936 
+0100
@@ -1,21 +1,3 @@
-# Host-side USB depends on having a host controller
-# NOTE:  dummy_hcd is always an option, but it's ignored here ...
-# NOTE:  SL-811 option should be board-specific ...
-config USB_ARCH_HAS_HCD
-   boolean
-   default y if USB_ARCH_HAS_OHCI
-   default y if ARM# SL-811
-   default PCI
-
-# many non-PCI hcds implement OHCI
-config USB_ARCH_HAS_OHCI
-   boolean
-   default y if SA
-   default y if ARCH_OMAP
-   default y if ARCH_LH7A404
-   default y if PXA27x
-   default PCI
-
 #
 # USB Host Controller Drivers
 #
Index: linux-2.6.11/drivers/usb/storage/Kconfig
===
--- linux-2.6.11.orig/drivers/usb/storage/Kconfig   2005-01-29 
22:50:43.297964628 +0100
+++ linux-2.6.11/drivers/usb/storage/Kconfig2005-01-29 22:56:58.568325936 
+0100
@@ -3,6 +3,7 @@
 #
 
 comment "NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be 
needed; see USB_STORAGE Help for more information"
+   depends on USB
 
 config USB_STORAGE
tristate "USB Mass Storage support"
Index: linux-2.6.11/drivers/usb/Kconfig
===
--- linux-2.6.11.orig/drivers/usb/Kconfig   2005-01-29 22:50:43.297964628 
+0100
+++ linux-2.6.11/drivers/usb/Kconfig2005-01-29 22:56:58.568325936 +0100
@@ -4,6 +4,24 @@
 
 menu "USB support"
 
+# Host-side USB depends on having a host controller
+# NOTE:  dummy_hcd is always an option, but it's ignored here ...
+# NOTE:  SL-811 option should be board-specific ...
+config USB_ARCH_HAS_HCD
+   boolean
+   default y if USB_ARCH_HAS_OHCI
+   default y if ARM# SL-811
+   default PCI
+
+# many non-PCI hcds implement OHCI
+config USB_ARCH_HAS_OHCI
+   boolean
+   default y if SA
+   default y if ARCH_OMAP
+   default y if ARCH_LH7A404
+   default y if PXA27x
+   default PCI
+
 # ARM SA chips have a non-PCI based "OHCI-compatible" USB host interface.
 config USB
tristate "Support for Host-side USB"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 7/8] Kconfig: cleanup sound menu

[Roman Zippel]

This properly indents the sound menu.

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 core/Kconfig |7 ++-
 oss/Kconfig  |8 
 2 files changed, 10 insertions(+), 5 deletions(-)

Index: linux-2.6.11/sound/oss/Kconfig
===
--- linux-2.6.11.orig/sound/oss/Kconfig 2005-01-29 22:56:42.549085439 +0100
+++ linux-2.6.11/sound/oss/Kconfig  2005-01-29 22:56:50.842656776 +0100
@@ -880,6 +880,10 @@ config SOUND_SB
  You can say M here to compile this driver as a module; the module is
  called sb.
 
+config SOUND_KAHLUA
+   tristate "XpressAudio Sound Blaster emulation"
+   depends on SOUND_SB
+
 config SOUND_AWE32_SYNTH
tristate "AWE32 synth"
depends on SOUND_OSS
@@ -1104,10 +1108,6 @@ config SOUND_TVMIXER
  Support for audio mixer facilities on the BT848 TV frame-grabber
  card.
 
-config SOUND_KAHLUA
-   tristate "XpressAudio Sound Blaster emulation"
-   depends on SOUND_SB
-
 config SOUND_ALI5455
tristate "ALi5455 audio support"
depends on SOUND_PRIME!=n && PCI
Index: linux-2.6.11/sound/core/Kconfig
===
--- linux-2.6.11.orig/sound/core/Kconfig2005-01-29 22:50:43.345956362 
+0100
+++ linux-2.6.11/sound/core/Kconfig 2005-01-29 22:56:50.843656604 +0100
@@ -1,16 +1,20 @@
 # ALSA soundcard-configuration
 config SND_TIMER
tristate
+   depends on SND
 
 config SND_PCM
tristate
select SND_TIMER
+   depends on SND
 
 config SND_HWDEP
tristate
+   depends on SND
 
 config SND_RAWMIDI
tristate
+   depends on SND
 
 config SND_SEQUENCER
tristate "Sequencer support"
@@ -40,6 +44,7 @@ config SND_SEQ_DUMMY
 
 config SND_OSSEMUL
bool
+   depends on SND
 
 config SND_MIXER_OSS
tristate "OSS Mixer API"
@@ -70,7 +75,7 @@ config SND_PCM_OSS
 
 config SND_SEQUENCER_OSS
bool "OSS Sequencer API"
-   depends on SND_SEQUENCER
+   depends on SND && SND_SEQUENCER
select SND_OSSEMUL
help
  Say Y here to enable OSS sequencer emulation (both
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/8] Kconfig: cleanup kernel hacking menu

[Roman Zippel]

This properly indents the kernel hacking menu.
Move LOG_BUF_SHIFT into kernel hacking menu (it already depended on 
DEBUG_KERNEL).
Add DEBUG_KERNEL dependency to EARLY_PRINTK, DEBUG_PREEMPT and FRAME_POINTER.
Remove overlong dependency, which included practically every arch.
Merge the two MAGIC_SYSRQ menu entries.
Remove unnecessary "default n" options.

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 arch/i386/Kconfig.debug |3 +-
 init/Kconfig|   20 --
 lib/Kconfig.debug   |   53 +++-
 3 files changed, 32 insertions(+), 44 deletions(-)

Index: linux-2.6.11/init/Kconfig
===
--- linux-2.6.11.orig/init/Kconfig  2005-01-29 22:50:43.457937076 +0100
+++ linux-2.6.11/init/Kconfig   2005-01-29 22:56:22.470544173 +0100
@@ -157,7 +157,6 @@ config SYSCTL
 config AUDIT
bool "Auditing support"
default y if SECURITY_SELINUX
-   default n
help
  Enable auditing infrastructure that can be used with another
  kernel subsystem, such as SELinux (which requires this for
@@ -168,29 +167,11 @@ config AUDITSYSCALL
bool "Enable system-call auditing support"
depends on AUDIT && (X86 || PPC64 || ARCH_S390 || IA64)
default y if SECURITY_SELINUX
-   default n
help
  Enable low-overhead system-call auditing infrastructure that
  can be used independently or with another kernel subsystem,
  such as SELinux.
 
-config LOG_BUF_SHIFT
-   int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" if DEBUG_KERNEL
-   range 12 21
-   default 17 if ARCH_S390
-   default 16 if X86_NUMAQ || IA64
-   default 15 if SMP
-   default 14
-   help
- Select kernel log buffer size as a power of 2.
- Defaults and Examples:
-17 => 128 KB for S/390
-16 => 64 KB for x86 NUMAQ or IA-64
-15 => 32 KB for SMP
-14 => 16 KB for uniprocessor
-13 =>  8 KB
-12 =>  4 KB
-
 config HOTPLUG
bool "Support for hot-pluggable devices" if !ARCH_S390
default ARCH_S390
@@ -304,7 +285,6 @@ config EPOLL
 config CC_OPTIMIZE_FOR_SIZE
bool "Optimize for size" if EMBEDDED
default y if ARM || H8300
-   default n
help
  Enabling this option will pass "-Os" instead of "-O2" to gcc
  resulting in a smaller kernel.
Index: linux-2.6.11/arch/i386/Kconfig.debug
===
--- linux-2.6.11.orig/arch/i386/Kconfig.debug   2005-01-29 22:50:43.458936904 
+0100
+++ linux-2.6.11/arch/i386/Kconfig.debug2005-01-29 22:56:22.470544173 
+0100
@@ -3,7 +3,7 @@ menu "Kernel hacking"
 source "lib/Kconfig.debug"
 
 config EARLY_PRINTK
-   bool "Early printk" if EMBEDDED
+   bool "Early printk" if EMBEDDED && DEBUG_KERNEL
default y
help
  Write kernel log output directly into the VGA buffer or to a serial
@@ -48,6 +48,7 @@ config DEBUG_PAGEALLOC
 
 config 4KSTACKS
bool "Use 4Kb for kernel stacks instead of 8Kb"
+   depends on DEBUG_KERNEL
help
  If you say Y here the kernel will use a 4Kb stacksize for the
  kernel stack attached to each process/thread. This facilitates
Index: linux-2.6.11/lib/Kconfig.debug
===
--- linux-2.6.11.orig/lib/Kconfig.debug 2005-01-29 22:50:43.458936904 +0100
+++ linux-2.6.11/lib/Kconfig.debug  2005-01-29 22:56:22.471544001 +0100
@@ -1,14 +1,13 @@
 
 config DEBUG_KERNEL
bool "Kernel debugging"
-   depends on (ALPHA || ARM || CRIS || H8300 || X86 || IA64 || M32R || 
M68K || M68KNOMMU || MIPS || PARISC || PPC32 || PPC64 || ARCH_S390 || SUPERH || 
SUPERH64 || SPARC32 || SPARC64 || USERMODE || V850 || X86_64)
help
  Say Y here if you are developing drivers or trying to debug and
  identify kernel problems.
 
 config MAGIC_SYSRQ
bool "Magic SysRq key"
-   depends on DEBUG_KERNEL && (ALPHA || ARM || X86 || IA64 || M32R || M68K 
|| MIPS || PARISC || PPC32 || PPC64 || ARCH_S390 || SUPERH || SUPERH64 || 
SPARC32 || SPARC64 || X86_64 || USERMODE)
+   depends on DEBUG_KERNEL
help
  If you say Y here, you will have some control over the system even
  if the system crashes for example during kernel debugging (e.g., you
@@ -20,12 +19,22 @@ config MAGIC_SYSRQ
  keys are documented in . Don't say Y
  unless you really know what this hack does.
 
-config MAGIC_SYSRQ
-   bool "Magic SysRq key"
-   depends on DEBUG_KERNEL && (H8300 || M68KNOMMU || V850)
-   help
- Enables console device to interpret special characters as
- commands to dump state information.
+config LOG_BUF_SHIFT
+   int "Kernel log buffer siz

[PATCH 3/8] Kconfig: cleanup cpufreq menu

[Roman Zippel]

This properly indents the cpufreq menu.
Remove CPU_FREQ_TABLE as visible option and use select instead.

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 arch/i386/kernel/cpu/cpufreq/Kconfig |   54 +++
 drivers/cpufreq/Kconfig  |   20 ++--
 2 files changed, 34 insertions(+), 40 deletions(-)

Index: linux-2.6.11/arch/i386/kernel/cpu/cpufreq/Kconfig
===
--- linux-2.6.11.orig/arch/i386/kernel/cpu/cpufreq/Kconfig  2005-01-29 
22:50:43.507928466 +0100
+++ linux-2.6.11/arch/i386/kernel/cpu/cpufreq/Kconfig   2005-01-29 
22:55:57.343872448 +0100
@@ -6,22 +6,14 @@ menu "CPU Frequency scaling"
 
 source "drivers/cpufreq/Kconfig"
 
-config CPU_FREQ_TABLE
-   tristate "CPU frequency table helpers"
-   depends on CPU_FREQ
-   default y
-   help
- Many CPUFreq drivers use these helpers, so only say N here if
-the CPUFreq driver of your choice doesn't need these helpers.
-
-If in doubt, say Y.
+if CPU_FREQ
 
 comment "CPUFreq processor drivers"
-   depends on CPU_FREQ
 
 config X86_ACPI_CPUFREQ
tristate "ACPI Processor P-States driver"
-   depends on CPU_FREQ_TABLE && ACPI_PROCESSOR
+   select CPU_FREQ_TABLE
+   depends on ACPI_PROCESSOR
help
  This driver adds a CPUFreq driver which utilizes the ACPI
  Processor Performance States.
@@ -32,7 +24,8 @@ config X86_ACPI_CPUFREQ
 
 config ELAN_CPUFREQ
tristate "AMD Elan"
-   depends on CPU_FREQ_TABLE && X86_ELAN
+   select CPU_FREQ_TABLE
+   depends on X86_ELAN
---help---
  This adds the CPUFreq driver for AMD Elan SC400 and SC410
  processors.
@@ -47,7 +40,7 @@ config ELAN_CPUFREQ
 
 config X86_POWERNOW_K6
tristate "AMD Mobile K6-2/K6-3 PowerNow!"
-   depends on CPU_FREQ_TABLE
+   select CPU_FREQ_TABLE
help
  This adds the CPUFreq driver for mobile AMD K6-2+ and mobile
  AMD K6-3+ processors.
@@ -58,7 +51,7 @@ config X86_POWERNOW_K6
 
 config X86_POWERNOW_K7
tristate "AMD Mobile Athlon/Duron PowerNow!"
-   depends on CPU_FREQ_TABLE
+   select CPU_FREQ_TABLE
help
  This adds the CPUFreq driver for mobile AMD K7 mobile processors.
 
@@ -68,12 +61,14 @@ config X86_POWERNOW_K7
 
 config X86_POWERNOW_K7_ACPI
bool
-   depends on ((X86_POWERNOW_K7 = "m" && ACPI_PROCESSOR) || 
(X86_POWERNOW_K7 = "y" && ACPI_PROCESSOR = "y"))
+   depends on X86_POWERNOW_K7 && ACPI_PROCESSOR
+   depends on !(X86_POWERNOW_K7 = y && ACPI_PROCESSOR = m)
default y
 
 config X86_POWERNOW_K8
tristate "AMD Opteron/Athlon64 PowerNow!"
-   depends on CPU_FREQ_TABLE && EXPERIMENTAL
+   select CPU_FREQ_TABLE
+   depends on EXPERIMENTAL
help
  This adds the CPUFreq driver for mobile AMD Opteron/Athlon64 
processors.
 
@@ -83,12 +78,12 @@ config X86_POWERNOW_K8
 
 config X86_POWERNOW_K8_ACPI
bool
-   depends on ((X86_POWERNOW_K8 = "m" && ACPI_PROCESSOR) || 
(X86_POWERNOW_K8 = "y" && ACPI_PROCESSOR = "y"))
+   depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
+   depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
default y
 
 config X86_GX_SUSPMOD
tristate "Cyrix MediaGX/NatSemi Geode Suspend Modulation"
-   depends on CPU_FREQ
help
 This add the CPUFreq driver for NatSemi Geode processors which
 support suspend modulation.
@@ -99,7 +94,7 @@ config X86_GX_SUSPMOD
 
 config X86_SPEEDSTEP_CENTRINO
tristate "Intel Enhanced SpeedStep"
-   depends on CPU_FREQ_TABLE
+   select CPU_FREQ_TABLE
select X86_SPEEDSTEP_CENTRINO_TABLE if (!X86_SPEEDSTEP_CENTRINO_ACPI)
help
  This adds the CPUFreq driver for Enhanced SpeedStep enabled
@@ -114,8 +109,8 @@ config X86_SPEEDSTEP_CENTRINO
 
 config X86_SPEEDSTEP_CENTRINO_ACPI
bool "Use ACPI tables to decode valid frequency/voltage pairs"
-   depends on X86_SPEEDSTEP_CENTRINO
-   depends on ((X86_SPEEDSTEP_CENTRINO = "m" && ACPI_PROCESSOR) || 
(X86_SPEEDSTEP_CENTRINO = "y" && ACPI_PROCESSOR = "y"))
+   depends on X86_SPEEDSTEP_CENTRINO && ACPI_PROCESSOR
+   depends on !(X86_SPEEDSTEP_CENTRINO = y && ACPI_PROCESSOR = m)
default y
help
  Use primarily the information provided in the BIOS ACPI tables
@@ -136,7 +131,7 @@ config X86_SPEEDSTEP_CENTRINO_TABLE
 
 config X86_SPEEDSTEP_ICH
tristate "Intel Speedstep on ICH-M chipsets (ioport interface)"
-   depends on CPU_FREQ_TABLE
+   select CPU_FREQ_TABLE
help
  This adds the CPUFreq driver for certain mobile Intel Pentium III
  (Coppermine), all mobile Intel Pentium III-M (Tualatin) and all
@@ -149,7 +144,8 @@ config X86_SPEEDSTEP_ICH
 
 config X86_SPEEDSTEP_SMI
tristate "Intel SpeedStep on 440BX/ZX/MX chipsets (SMI interface)"
-   depends on CPU_FREQ_TAB

[PATCH 1/8] Kconfig: cleanup ACPI menu

[Roman Zippel]

This properly indents the ACPI menu.
Hide ACPI_BLACKLIST_YEAR when not needed.

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 Kconfig |   36 +---
 1 files changed, 13 insertions(+), 23 deletions(-)

Index: linux-2.6.11/drivers/acpi/Kconfig
===
--- linux-2.6.11.orig/drivers/acpi/Kconfig  2005-01-29 22:50:43.609910902 
+0100
+++ linux-2.6.11/drivers/acpi/Kconfig   2005-01-29 22:55:05.068877064 +0100
@@ -40,21 +40,23 @@ config ACPI
  available at:
  
 
+if ACPI
+
 config ACPI_BOOT
bool
-   depends on ACPI || X86_HT
+   depends on X86_HT
default y
 
 config ACPI_INTERPRETER
bool
-   depends on ACPI
depends on !IA64_SGI_SN
default y
 
+if ACPI_INTERPRETER
+
 config ACPI_SLEEP
bool "Sleep States (EXPERIMENTAL)"
-   depends on X86 && ACPI
-   depends on ACPI_INTERPRETER
+   depends on X86
depends on EXPERIMENTAL && PM
default y
---help---
@@ -81,7 +83,6 @@ config ACPI_SLEEP_PROC_FS
 config ACPI_AC
tristate "AC Adapter"
depends on X86
-   depends on ACPI_INTERPRETER
default m
help
  This driver adds support for the AC Adapter object, which indicates
@@ -91,7 +92,6 @@ config ACPI_AC
 config ACPI_BATTERY
tristate "Battery"
depends on X86
-   depends on ACPI_INTERPRETER
default m
help
  This driver adds support for battery information through
@@ -100,7 +100,6 @@ config ACPI_BATTERY
 
 config ACPI_BUTTON
tristate "Button"
-   depends on ACPI_INTERPRETER
depends on !IA64_SGI_SN
default m
help
@@ -112,7 +111,6 @@ config ACPI_BUTTON
 
 config ACPI_VIDEO
tristate "Video"
-   depends on ACPI_INTERPRETER
depends on EXPERIMENTAL
depends on !IA64_SGI_SN
default m
@@ -127,7 +125,6 @@ config ACPI_VIDEO
 
 config ACPI_FAN
tristate "Fan"
-   depends on ACPI_INTERPRETER
depends on !IA64_SGI_SN
default m
help
@@ -136,7 +133,6 @@ config ACPI_FAN
 
 config ACPI_PROCESSOR
tristate "Processor"
-   depends on ACPI_INTERPRETER
depends on !IA64_SGI_SN
default m
help
@@ -165,7 +161,6 @@ config ACPI_THERMAL
 
 config ACPI_NUMA
bool "NUMA support"
-   depends on ACPI_INTERPRETER
depends on NUMA
depends on (IA64 || X86_64)
default y if IA64_GENERIC || IA64_SGI_SN2
@@ -173,7 +168,6 @@ config ACPI_NUMA
 config ACPI_ASUS
 tristate "ASUS/Medion Laptop Extras"
depends on X86
-   depends on ACPI_INTERPRETER
default m
 ---help---
   This driver provides support for extra features of ACPI-compatible
@@ -203,7 +197,6 @@ config ACPI_ASUS
 config ACPI_IBM
tristate "IBM ThinkPad Laptop Extras"
depends on X86
-   depends on ACPI_INTERPRETER
default m
---help---
  This is a Linux ACPI driver for the IBM ThinkPad laptops. It adds
@@ -217,7 +210,6 @@ config ACPI_IBM
 config ACPI_TOSHIBA
tristate "Toshiba Laptop Extras"
depends on X86
-   depends on ACPI_INTERPRETER
default m
---help---
  This driver adds support for access to certain system settings
@@ -244,7 +236,7 @@ config ACPI_TOSHIBA
 
 config ACPI_CUSTOM_DSDT
bool "Include Custom DSDT"
-   depends on ACPI_INTERPRETER && !STANDALONE
+   depends on !STANDALONE
default n 
help
  Thist option is to load a custom ACPI DSDT
@@ -270,7 +262,6 @@ config ACPI_BLACKLIST_YEAR
 
 config ACPI_DEBUG
bool "Debug Statements"
-   depends on ACPI_INTERPRETER
depends on !IA64_SGI_SN
default n
help
@@ -280,14 +271,12 @@ config ACPI_DEBUG
 
 config ACPI_BUS
bool
-   depends on ACPI_INTERPRETER
depends on !IA64_SGI_SN
default y
 
 config ACPI_EC
bool
depends on X86
-   depends on ACPI_INTERPRETER
default y
help
  This driver is required on some systems for the proper operation of
@@ -296,28 +285,27 @@ config ACPI_EC
 
 config ACPI_POWER
bool
-   depends on ACPI_INTERPRETER
depends on !IA64_SGI_SN
default y
 
 config ACPI_PCI
bool
-   depends on ACPI_INTERPRETER
depends on !IA64_SGI_SN
default PCI
 
 config ACPI_SYSTEM
bool
-   depends on ACPI_INTERPRETER
depends on !IA64_SGI_SN
default y
help
  This driver will enable your system to shut down using ACPI, and
  dump your ACPI DSDT table using /proc/acpi/dsdt.
 
+endif  # ACPI_INTERPRETER
+
 config X86_PM_TIMER
bool "Power Management Timer Support"
-   depends on X86 && ACPI
+   depends on X86
depends on ACPI_BOOT && EXPERIMENTAL
depends on !X86_64
defaul

[PATCH 2/8] Kconfig: cleanup bus options menu

[Roman Zippel]

This properly indents the bus options menu.
Merge the two MCA menu entries.
Remove unnecessary "default n" options.

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 arch/i386/Kconfig|8 ++--
 drivers/pci/Kconfig  |2 +-
 drivers/pci/pcie/Kconfig |2 +-
 drivers/pcmcia/Kconfig   |   11 ++-
 4 files changed, 10 insertions(+), 13 deletions(-)

Index: linux-2.6.11/drivers/pcmcia/Kconfig
===
--- linux-2.6.11.orig/drivers/pcmcia/Kconfig2005-01-29 22:50:43.566918306 
+0100
+++ linux-2.6.11/drivers/pcmcia/Kconfig 2005-01-29 22:55:48.773348778 +0100
@@ -20,9 +20,10 @@ config PCCARD
  To compile this driver as modules, choose M here: the
  module will be called pcmcia_core.
 
+if PCCARD
+
 config PCMCIA_DEBUG
bool "Enable PCCARD debugging"
-   depends on PCCARD != n
help
  Say Y here to enable PCMCIA subsystem debugging.  You
  will need to choose the debugging level either via the
@@ -41,7 +42,6 @@ config PCMCIA_DEBUG
 
 config PCMCIA
tristate "16-bit PCMCIA support"
-   depends on PCCARD
default y
---help---
   This option enables support for 16-bit PCMCIA cards. Most older
@@ -60,7 +60,7 @@ config PCMCIA
 
 config CARDBUS
bool "32-bit CardBus support"   
-   depends on PCCARD && PCI
+   depends on PCI
default y
---help---
  CardBus is a bus mastering architecture for PC-cards, which allows
@@ -77,7 +77,7 @@ comment "PC-card bridges"
 
 config YENTA
tristate "CardBus yenta-compatible bridge support"
-   depends on PCCARD && PCI
+   depends on PCI
 #fixme: remove dependendcy on CARDBUS
depends on CARDBUS
select PCCARD_NONSTATIC
@@ -197,6 +197,7 @@ config PCMCIA_VRC4173
 
 config PCCARD_NONSTATIC
tristate
-   depends on PCCARD
+
+endif  # PCCARD
 
 endmenu
Index: linux-2.6.11/drivers/pci/pcie/Kconfig
===
--- linux-2.6.11.orig/drivers/pci/pcie/Kconfig  2005-01-29 22:50:43.566918306 
+0100
+++ linux-2.6.11/drivers/pci/pcie/Kconfig   2005-01-29 22:55:48.773348778 
+0100
@@ -3,8 +3,8 @@
 #
 config PCIEPORTBUS
bool "PCI Express support"
+   depends on PCI
depends on PCI_GOMMCONFIG || PCI_GOANY
-   default n
 
---help---
This automatically enables PCI Express Port Bus support. Users can
Index: linux-2.6.11/drivers/pci/Kconfig
===
--- linux-2.6.11.orig/drivers/pci/Kconfig   2005-01-29 22:50:43.566918306 
+0100
+++ linux-2.6.11/drivers/pci/Kconfig2005-01-29 22:55:48.773348778 +0100
@@ -3,8 +3,8 @@
 #
 config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
+   depends on PCI
depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64
-   default n
help
   This allows device drivers to enable MSI (Message Signaled
   Interrupts).  Message Signaled Interrupts enable a device to
Index: linux-2.6.11/arch/i386/Kconfig
===
--- linux-2.6.11.orig/arch/i386/Kconfig 2005-01-29 22:50:43.566918306 +0100
+++ linux-2.6.11/arch/i386/Kconfig  2005-01-29 22:55:48.774348606 +0100
@@ -1200,18 +1200,14 @@ config EISA
 source "drivers/eisa/Kconfig"
 
 config MCA
-   bool "MCA support"
-   depends on !(X86_VISWS || X86_VOYAGER)
+   bool "MCA support" if !(X86_VISWS || X86_VOYAGER)
+   default y if X86_VOYAGER
help
  MicroChannel Architecture is found in some IBM PS/2 machines and
  laptops.  It is a bus system similar to PCI or ISA. See
   (and especially the web page given
  there) before attempting to build an MCA bus kernel.
 
-config MCA
-   depends on X86_VOYAGER
-   default y if X86_VOYAGER
-
 source "drivers/mca/Kconfig"
 
 config SCx200
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/8] Kconfig: cleanup the menu structure

[Roman Zippel]

Hi,

The following patches cleans up some of the worst offenders, which mess up 
the kconfig menu structure. The patches apply to 2.6.11-rc2-mm2 and 
2.6.11-rc2-bk7, the only exception is the one below. Andrew, I leave it 
to you what to do with it, maybe fold it directly into kgdb-ga.patch?

bye, Roman

---

 Kconfig.debug |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.11/arch/i386/Kconfig.debug
===
--- linux-2.6.11.orig/arch/i386/Kconfig.debug   2005-01-29 22:56:22.470544173 
+0100
+++ linux-2.6.11/arch/i386/Kconfig.debug2005-01-29 22:58:15.270112850 
+0100
@@ -56,6 +56,8 @@ config 4KSTACKS
  on the VM subsystem for higher order allocations. This option
  will also use IRQ stacks to compensate for the reduced stackspace.
 
+source "arch/i386/Kconfig.kgdb"
+
 config X86_FIND_SMP_CONFIG
bool
depends on X86_LOCAL_APIC || X86_VOYAGER
@@ -66,6 +68,4 @@ config X86_MPPARSE
depends on X86_LOCAL_APIC && !X86_VISWS
default y
 
-source "arch/i386/Kconfig.kgdb"
-
 endmenu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Yenta CardBus IRQ storm disabling interrupt

[Mike Cumings]

Russell,

I doubt that this issue is specifically related to the card being
used.  I just recalled the fact that the IRQ probing done by the
yenta_socket driver code has run into the IRQ storm at
boot time as well, without any cards in the slots.

Another piece of info for the pile.

Mike


On Sat, 29 Jan 2005 12:57:56 -0800, Mike Cumings <[EMAIL PROTECTED]> wrote:
> Hi Russell,
> 
> This is a different card (NetGear WG511U) than the USB card that
> was discussed in the previous thread.  I haven't tried a 2.4.x kernel
> yet, but that was on my list of things to do. :)  Unfortunately, this is
> the only machine I've got which has CardBus so I'd have a hard time
> attempting to reproduce on another machine.
> 
> Mike
> 
> 
> On Sat, 29 Jan 2005 20:53:45 +, Russell King
> <[EMAIL PROTECTED]> wrote:
> > On Sat, Jan 29, 2005 at 12:42:17PM -0800, Mike Cumings wrote:
> > > In my Googling, I encountered a thread on January 10th of this year 
> > > entitled
> > > "yenta_socket rapid fires interrupts" (between Dick Hollenbeck, Linus,
> > > and others)
> >
> > Out of interest, is it the same cardbus card you're inserting into
> > the socket as the problem mentioned above?
> >
> > I think what is suspected is that the Cardbus card is holding its
> > interrupt output active.  This normally shares the same interrupt
> > as the yenta socket status change interrupt, and, since we're
> > listening for interrupts from the card, it causes this problem.
> >
> > A thought: can you reproduce this problem with 2.4?  Has this cardbus
> > card been used with other Linux kernels?  On other machines?
> >
> > I suspect what you'll find is that any Linux kernel on any machine
> > with this card will exhibit this problem - which would prove my
> > theory.
> >
> > --
> > Russell King
> >  Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
> >  maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
> >  2.6 Serial core
> >
> 
> 
> --
> Mike Cumings
> 


-- 
Mike Cumings
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] OProfile: Fix oops on undetected CPU type

[Zwane Mwaikambo]

On Sat, 29 Jan 2005, John Levon wrote:

> Looks like you're still on the broken bkcvs, which is missing this
> patch:
> 
> http://linus.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|[EMAIL PROTECTED]
> 
> which AFAICS is the correct solution to the problem.

Hmm i was actually using BK and not BKCVS and had pulled after the 25th. 
Anyway thanks, that should do it then.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] OProfile: Fix oops on undetected CPU type

[John Levon]

On Sat, Jan 29, 2005 at 09:47:42AM -0700, Zwane Mwaikambo wrote:

> > Unfortunately bkcvs seems out of date so I can't even look at this
> > myself.
> 
> Yes you are right, i checked bk and there was a lot of shuffling about due 
> to the timer override. But it looks like we're depending on the timer 
> variable being set. We could always just run timer_init if cpu_type is not 
> set.
> 
> Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
> 
> = drivers/oprofile/oprof.c 1.11 vs edited =
> --- 1.11/drivers/oprofile/oprof.c 2005-01-04 19:48:23 -07:00
> +++ edited/drivers/oprofile/oprof.c   2005-01-29 09:38:24 -07:00
> @@ -157,7 +157,7 @@ static int __init oprofile_init(void)
>  
>   oprofile_arch_init(&oprofile_ops);
>  
> - if (timer) {
> + if (timer || !oprofile_ops.cpu_type) {

Looks like you're still on the broken bkcvs, which is missing this
patch:

http://linus.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|[EMAIL PROTECTED]

which AFAICS is the correct solution to the problem.

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

Re: kbuild: Implicit dependence on the C compiler

[Sam Ravnborg]

On Mon, Jan 17, 2005 at 02:03:41PM -0800, H. Peter Anvin wrote:
> >There is no way to tell kbuild "ignore gcc change"
> 
> There really needs to be one.

make KBUILD_NOCMDDEP=1
will do what you want - at least I have it in my tree now.
I could not just ignore 'gcc' - but had to ignore the full commandline.

This is due to more complex commands like:
rm -f file; $(LD) ...

Within the Makefile.lib when I check KBUILD_NOCMDDEP there is no
knowledge of the actual command being executed. And an implmentation
that just filtered out $(CC) was too ugly.
And due to the above mentioned command I could not just skip the first
word on the command line.


I will push my bk tree soon and it will show up in next -mm.

It is not perfect in the sense that the last part of the build will get
redone (GEN .version and onwards). This is fixable but not worth it
right now.

So with current implmentation executing:

make

make KBUILD_NOCMDDEP=1 CROSS_COMPILE=i586-pc-linux-gnu-

will result in only a few files being rebuild - and not the whole
kernel as before.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc2-mm2

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm2/




Changes since 2.6.11-rc2-mm1:



 linus.patch
 bk-agpgart.patch
 bk-alsa.patch
 bk-arm.patch
 bk-cifs.patch
 bk-cpufreq.patch
 bk-driver-core.patch
 bk-drm.patch
 bk-drm-via.patch
 bk-i2c.patch
 bk-ide-dev.patch
 bk-netdev.patch
 bk-ntfs.patch
 bk-usb.patch
 bk-watchdog.patch
 bk-xfs.patch

 Latest versions of external bk trees

-dib3000mc-build-fix.patch
-fbdev-screen-corruption-fix.patch
-mips-fixed-conflicting-types.patch
-oprofile-falling-back-on-timer-interrupt-mode.patch
-compat-ioctl-security-hook-fixup.patch
-ia64-acpi-build-fix.patch
-hda_intel-fix.patch
-mm-adjust-dirty-threshold-for-lowmem-only-mappings.patch
-mm-truncate-smp-race-fix.patch
-pcnet32-79c976-with-fiber-optic.patch
-add-omap-support-to-smc91x-ethernet-driver.patch
-netpoll-fix-napi-polling-race-on-smp.patch
-tun-tan-arp-monitor-support.patch
-atmel_cs-add-support-lg-lw2100n-wlan-pcmcia-card.patch
-smc91x-power-down-phy-on-suspend.patch
-e100-locking-up-netconsole.patch
-ppc32-add-defconfigs-for-85xx-boards-updated.patch
-ppc32-allow-usage-of-gen550-on-platforms-that-do-not-define.patch
-ppc32-missing-call-to-ioremap-in-pci_iomap.patch
-ppc32-fix-pci2-io-space-mapping-on-cds.patch
-ppc32-add-support-for-pegasos-machines.patch
-ppc64-limit-segment-tables-on-up-kernels.patch
-ppc64-xmon-data-breakpoints-on-partitioned-systems.patch
-ppc64-fix-in_be64-definition.patch
-ppc64-clear-msr_ri-earlier-in-syscall-exit-path.patch
-ppc64-replace-schedule_timeout-in-iseries_pci_reset.patch
-ppc64-replace-schedule_timeout-in-pseries_cpu_die.patch
-ppc64-replace-schedule_timeout-in-__cpu_up.patch
-ppc64-replace-schedule_timeout-in-die.patch
-ppc64-trivial-cleanup-eeh_region.patch
-ppc64-sparse-fixes-for-cpu-feature-constants.patch
-ppc64-use-kref-for-device_node-refcounting.patch
-ppc64-allow-eeh-to-be-disabled.patch
-ppc64-disable-some-boot-wrapper-debug.patch
-ppc64-problem-disabling-sysvipc.patch
-ppc64-enable-virtual-ethernet-and-virtual-scsi.patch
-x86-no-interrupts-from-secondary-cpus-until-officially-online.patch
-x86-remove-unused-function.patch
-x86_64-remove-centaur-mtrr-support.patch
-x86_64-remove-duplicated-includes.patch
-x86_64-enlarge-northbridge-numa-scan-mask.patch
-x86_64-remove-earlyprintk-help.patch
-x86_64-speed-up-suspend.patch
-h8300-fix-warning.patch
-h8300-makefile-update.patch
-swsusp-comment-fix.patch
-kill-softirq_pending.patch
-kill-softirq_pending-fix.patch
-clean-up-uts_release-usage.patch
-3c59x-ethtool-provide-nic-specific-stats.patch
-ext2-ext3-block-allocator-startup-fix.patch
-ext3-quota-leak-fix.patch
-ext3-ea-no-lock-needed-when-freeing-inode.patch
-ext3-ea-set-the-ext3_feature_compat_ext_attr-for-in-inode-xattrs.patch
-ext3-ea-documentation-fix.patch
-ext3-ea-fix-i_extra_isize-check.patch
-ext3-ea-disallow-in-inode-attributes-for-reserved-inodes.patch
-ext3-fix-ea-in-inode-default-acl-creation.patch
-ext2-ext3-acls-remove-the-number-of-acl-entries-limit.patch
-i810_audio-offset-lvi-from-civ-to-avoid-stalled-start.patch
-configurable-delay-before-mounting-root-device.patch
-fs-mbcachec-remove-an-unused-wait-queue-variable.patch
-device-mapper-fix-mirror-log-type-module-ref-count.patch
-device-mapper-remove-unused-bs_bio_init.patch
-device-mapper-add-presuspend-hook.patch
-device-mapper-optionally-bypass-a-bdget.patch
-device-mapper-fix-tb-stripe-data-corruption.patch
-arm26-new-maintainer-of-archimedes-floppy-and-hard-disk-drivers.patch
-problems-disabling-sysctl.patch
-genhd-rename-device_init.patch
-infiniband-core-compat_ioctl-conversion-minor-fixes.patch
-infiniband-mthca-more-arbel-mem-free-support.patch
-infiniband-mthca-implement-modifying-port-attributes.patch
-infiniband-core-fix-port-capability-enums-bit-order.patch
-infiniband-mthca-dont-write-ecr-in-msi-x-mode.patch
-infiniband-mthca-pass-full-process_mad-info-to-firmware.patch
-infiniband-mthca-optimize-event-queue-handling.patch
-infiniband-mthca-test-irq-routing-during-initialization.patch
-infiniband-ipoib-remove-uses-of-yield.patch
-infiniband-core-add-issm-userspace-support.patch
-infiniband-mthca-clean-up-ioremap-request_region-usage.patch
-infiniband-mthca-remove-x86-sse-pessimization.patch
-pcmcia-tcic-eleminate-deprecated-check_region.patch
-pcmcia-i82365-use-config_pnp-instead-of-__isapnp__.patch
-pcmcia-i82092-fix-checking-of-return-value-from-request_region.patch
-pcmcia-socket-acregion-are-unused.patch
-pcmcia-use-unsigned-long-for-io-port-address.patch
-videotext-ioctls-changed-to-use-_io-macros.patch
-video-arv-remove-casts.patch
-video-w9966-remove-casts.patch
-video-zr36120-remove-casts.patch
-v4l-video-buf-update.patch
-v4l2-tuner-api-update.patch
-v4l-tuner-update.patch
-v4l-add-tveeprom-module.patch
-v4l-tvaudio-update.patch
-v4l-bttv-ir-input-driver-update.patch
-v4l-bttv-update.patch
-v4l-saa7134-module.patch
-radeonfb-set-accelerator-id.patch
-vesafb-change-return-error-id.patch
-intelfb-workaround-for-830m.patch
-fbcon-save-blank

DRI (was Re: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*)

[Lee Revell]

On Sat, 2005-01-29 at 15:57 -0500, Parag Warudkar wrote:
> Dr. David Alan Gilbert wrote:
> 
> >* Lee Revell ([EMAIL PROTECTED]) wrote:
> >  
> >
> >>Stupid question: what the heck does OO use DRI for?  I googled and came
> >>up empty.
> >>
> >>
> >
> >It does pointless 3D objects in its drawing package.
> >  
> >
> Another stupid question :)
> Does it mean DRI is only used for doing 3D? How about normal, 2D stuff? 
> I thought X uses DRI for both 2D  and 3D if it is available...
> 

No, XAA is normally used for 2D acceleration.  This is hardware
accelerated but doesn't use DRI, X does 2D accel by talking directly to
the hardware without the kernel's involvement.

This is an area where the proprietary guys are a little ahead but there
are some interesting developments like the Xgl server.

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: Yenta CardBus IRQ storm disabling interrupt

[Mike Cumings]

Hi Russell,

This is a different card (NetGear WG511U) than the USB card that
was discussed in the previous thread.  I haven't tried a 2.4.x kernel
yet, but that was on my list of things to do. :)  Unfortunately, this is
the only machine I've got which has CardBus so I'd have a hard time
attempting to reproduce on another machine.

Mike


On Sat, 29 Jan 2005 20:53:45 +, Russell King
<[EMAIL PROTECTED]> wrote:
> On Sat, Jan 29, 2005 at 12:42:17PM -0800, Mike Cumings wrote:
> > In my Googling, I encountered a thread on January 10th of this year entitled
> > "yenta_socket rapid fires interrupts" (between Dick Hollenbeck, Linus,
> > and others)
> 
> Out of interest, is it the same cardbus card you're inserting into
> the socket as the problem mentioned above?
> 
> I think what is suspected is that the Cardbus card is holding its
> interrupt output active.  This normally shares the same interrupt
> as the yenta socket status change interrupt, and, since we're
> listening for interrupts from the card, it causes this problem.
> 
> A thought: can you reproduce this problem with 2.4?  Has this cardbus
> card been used with other Linux kernels?  On other machines?
> 
> I suspect what you'll find is that any Linux kernel on any machine
> with this card will exhibit this problem - which would prove my
> theory.
> 
> --
> Russell King
>  Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
>  2.6 Serial core
> 


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

Re: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

[Parag Warudkar]

Dr. David Alan Gilbert wrote:
* Lee Revell ([EMAIL PROTECTED]) wrote:
 

Stupid question: what the heck does OO use DRI for?  I googled and came
up empty.
   

It does pointless 3D objects in its drawing package.
 

Another stupid question :)
Does it mean DRI is only used for doing 3D? How about normal, 2D stuff? 
I thought X uses DRI for both 2D  and 3D if it is available...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Yenta CardBus IRQ storm disabling interrupt

[Russell King]

On Sat, Jan 29, 2005 at 12:42:17PM -0800, Mike Cumings wrote:
> In my Googling, I encountered a thread on January 10th of this year entitled
> "yenta_socket rapid fires interrupts" (between Dick Hollenbeck, Linus,
> and others)

Out of interest, is it the same cardbus card you're inserting into
the socket as the problem mentioned above?

I think what is suspected is that the Cardbus card is holding its
interrupt output active.  This normally shares the same interrupt
as the yenta socket status change interrupt, and, since we're
listening for interrupts from the card, it causes this problem.

A thought: can you reproduce this problem with 2.4?  Has this cardbus
card been used with other Linux kernels?  On other machines?

I suspect what you'll find is that any Linux kernel on any machine
with this card will exhibit this problem - which would prove my
theory.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

[Lee Revell]

On Sat, 2005-01-29 at 20:40 +, Dr. David Alan Gilbert wrote:
> * Lee Revell ([EMAIL PROTECTED]) wrote:
> > 
> > Stupid question: what the heck does OO use DRI for?  I googled and came
> > up empty.
> 
> It does pointless 3D objects in its drawing package.
> 

Thanks.  I knew it had to be something really clever, or something
really stupid ;-)

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/

adding process data to file descriptor structure

[ych43]

Hi,
  In current linux kernel, file descriptors do not include a process data. So 
if it is possible to add process data to file descriptor structures in Linux 
kernel. So a file descriptor could save a list of proc pointers or a list of 
PID values. If this list can be implemented, then sockets can be easily 
identified using protocol control block hash table.
 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/

Yenta CardBus IRQ storm disabling interrupt

[Mike Cumings]

Good day gurus,

I've got an IRQ storm resulting in a useless CardBus bridge that I am having
a hard time debugging.  I've seen this on 2.6.9, 2.6.10, and 2.6.11-rc2 which is
what I'm currently testing against.

For some reason I'm getting an IRQ storm when attempting to use a TI1225
CardBus bridge (Yenta-compatible).  Oddly enough, the storm happens more 
frequently with one PCCard than another in my possession, but both have 
encountered the infamous "Disabling IRQ #??" (in my case, IRQ 11).

In my Googling, I encountered a thread on January 10th of this year entitled
"yenta_socket rapid fires interrupts" (between Dick Hollenbeck, Linus,
and others)
which describes the same fail mode, but for a different TI card.  It
doesnt appear
in that thread that there was any resolution.  I'd like to help change that if
possible! ;)  I ended up adding a good amount of verbosity to the yenta_socket.c
file in an effort to figure out what is going on, but the TI bridge
appears to be
operating fine from what I can tell.  Here is a dmesg snippet of a failure:

...
Yenta: Begin yenta_probe
Yenta: Enabing PCI Device
PCI: :00:04.0 has unsupported PM cap regs version (1)
PCI: Current state: (4)
PCI: Desired state: (0)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt :00:04.0[A] -> GSI 11 (level, low) -> IRQ 11
Yenta: Request Regions
Yenta: Start Resource
Yenta: Map regs and request IRQ
Yenta: CardBus bridge found at :00:04.0 [1028:009e]
Yenta: Config init
Yenta: Diable events
Yenta: Setup bridge regions
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket :00:04.0, mfunc 0x01021c72, devctl 0x66
Yenta TI: pre intctl=50
Yenta TI: post intctl=50
Yenta: Bridge control pre =05c0
Yenta: Bridge control post=0540
Yenta: Requesting IRQ: b
Yenta: Generating interrupt
Yenta: Probe handler: cb_event=0001
Yenta: Probe handler:  CSC=00
Yenta: Disabling interrupts
Yenta: CSC: 0
Yenta: Returning socket status: 1
Yenta: Finish init
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 3006
Yenta: Register with PCMCIA layer
Yenta: Begin yenta_probe
Yenta: Enabing PCI Device
PCI: :00:04.1 has unsupported PM cap regs version (1)
PCI: Current state: (4)
PCI: Desired state: (0)
Yenta: Request Regions
Yenta: Start Resource
Yenta: Map regs and request IRQ
Yenta: CardBus bridge found at :00:04.1 [1028:009e]
Yenta: Config init
Yenta: Diable events
Yenta: Setup bridge regions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket :00:04.1, mfunc 0x01021c72, devctl 0x66
Yenta: Bridge control pre =0580
Yenta: Bridge control post=0500
Yenta: Requesting IRQ: b
Yenta: Generating interrupt
Yenta: Storm#=01/25 event= state=3006 csc=00 intctl=50
Yenta: Probe handler: cb_event=0001
Yenta: Probe handler:  CSC=00
Yenta: Disabling interrupts
Yenta: CSC: 0
Yenta: Returning socket status: 1
Yenta: Finish init
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 3069
Yenta: Register with PCMCIA layer
...
Yenta: Storm#=02/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=03/25 event=0006 state=3026 csc=08 intctl=50
Yenta: Resetting storm counter
Yenta: Storm#=01/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=02/25 event=0004 state=3082 csc=00 intctl=50
Yenta: Resetting storm counter
Yenta: Storm#=01/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=02/25 event=0004 state=3086 csc=00 intctl=50
Yenta: Resetting storm counter
Yenta: Storm#=01/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=02/25 event=0006 state=3820 csc=08 intctl=50
Yenta: Resetting storm counter
Yenta: Storm#=01/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=02/25 event=0008 state=3829 csc=00 intctl=50
Yenta: Storm#=03/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=04/25 event= state=3829 csc=00 intctl=50
Yenta: Storm#=05/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=06/25 event= state=3829 csc=00 intctl=50
Yenta: Storm#=07/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=08/25 event= state=3829 csc=00 intctl=50
Yenta: Storm#=09/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=10/25 event= state=3829 csc=00 intctl=50
Yenta: Storm#=11/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=11/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=12/25 event= state=3829 csc=00 intctl=50
Yenta: Storm#=13/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=14/25 event= state=3829 csc=00 intctl=50
Yenta: Storm#=15/25 event= state=3006 csc=00 intctl=50
Yenta: Storm#=16/25 event= state=3829 csc=00 intctl=50
Yenta: Storm#=17/25 e

Re: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

[Gene Heskett]

On Saturday 29 January 2005 14:25, Jon Smirl wrote:
>On Sat, 29 Jan 2005 13:02:51 +, Richard Hughes 
<[EMAIL PROTECTED]> wrote:
>> On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
>> > Note, that strace glxgears gives exactly the same output, going
>> > from 0 to 14 and then seg-faulting, so it's *not just a oo
>> > problem*.
>>
>> I know it's bad to answer your own post, but here goes.
>>
>> I changed my /etc/udev/permissions.d/50-udev.permissions config to
>> read:
>>
>> dri/*:root:root:0666
>>
>> changing it from
>>
>> dri/*:root:root:0660
>>
>> And oowriter and glxgears work from bootup. Shall I file a bug
>> with udev?
>
>Your user ID needs to belong to group DRI.

Humm, scratching head here.  My /etc/group file contains no references 
to dri, but as root at least, it works just fine, X-6.8.1 here.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.32% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

[Dr. David Alan Gilbert]

* Lee Revell ([EMAIL PROTECTED]) wrote:
> 
> Stupid question: what the heck does OO use DRI for?  I googled and came
> up empty.

It does pointless 3D objects in its drawing package.

Dave
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.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/

Re: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

[Lee Revell]

On Sat, 2005-01-29 at 14:25 -0500, Jon Smirl wrote:
>  
> > And oowriter and glxgears work from bootup. Shall I file a bug with udev?
> 
> Your user ID needs to belong to group DRI.
> 

Stupid question: what the heck does OO use DRI for?  I googled and came
up empty.

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: AT keyboard dead on 2.6

[Wiktor]

Do you still need atkbd.reset=1?
No, i don't. i've just tried it, because when keyboard was not working, 
the only error report was produced by this option.

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

Re: AT keyboard dead on 2.6

[Wiktor]

Wiktor, can you try atkbd.dumbkbd=1?
Here you are full dmesg (see attachment). i've been typing alphabet 
after kernel boot.


atkbd.dumpkbd.gz
Description: application/gzip

Re: AT keyboard dead on 2.6

[Wiktor]

It still looks OK. It seems to be a very ancient keyboard. Can you try with
a newer one? That'd tell us whether it's the controller or the keyboard
that is giving problems.
What keyboard model is it? What machine?
Machine info attached as a part of /dev/proc. i've tried with another AT 
keyboard and PS/2 keyboard attached via connector - results were the 
same. keyboard i'm using is: chicony model KB-5911 serial 6A00152705. 
what does it mean 'ancient'? mine keyb has about 10 years. is it ancient 
or not (it is the first keyboard i've been using)?

--
May the Source be with you.
wixor


sysinfo.tar.bz2
Description: Binary data

Re: i8042 access timings

[Randy.Dunlap]

Vojtech Pavlik wrote:
On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote:
Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:

So what _might_ happen is that we write the command, and then 
i8042_wait_write() thinks that there is space to write the data 
immediately, and writes the data, but now the data got lost because the 
buffer was busy.
Hmm - I just answered the same post and concluded that I didnt understand,
so you have progressed further. I considered the same possibility,
but the data was not lost since we read it again later.
Only the ready flag was lost.

What I believe is happening is that we're talking to SMM emulation of
the i8042, which doesn't have a clue about these commands, while the
underlying real hardware implementation does. And because of that they
disagree on what should happen when the command is issued, and since the
SMM emulation lazily synchronizes with the real HW, we only get the data
back with the next command.
I still don't have an explanation why both 'usb-handoff' and 'acpi=off'
help, I'd expect only the first to, but it might be related to the SCI
interrupt routing which isn't done when 'acpi=off'. Just a wild guess.
Ok, I'm not too clued up with recent hardware and the BIOS programming 
that goes with it (being a system admin/application programmer), what 
exactly is usb-handoff?

usb-handoff is a kernel option that enables a PCI quirk routine that
takes the USB controller out of BIOS's hands. Until that is done (the
linux USB drivers also do it, only later), the BIOS owns the USB
controller and tries to emulate a PS/2 mouse and keyboard for systems
which can't handle USB.

acpi=off obviously just turns all acpi support 
in the kernel off. 

Indeed.

SCI is also a new abbreviation I haven't seen 
before.

System Configuration Interrupt. In addition to SMI (System Management
Interrupt), these are two interrupts the BIOS uses to do its job behind
the operating system's back.
ACPI 2.0 spec says:
System Control Interrupt (SCI)
A system interrupt used by hardware to notify the OS of ACPI events. 
The SCI is an active, low, shareable, level interrupt.

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

Re: i8042 access timings

[Jaco Kroon]

Vojtech Pavlik wrote:
What I believe is happening is that we're talking to SMM emulation of
the i8042, which doesn't have a clue about these commands, while the
underlying real hardware implementation does. And because of that they
disagree on what should happen when the command is issued, and since the
SMM emulation lazily synchronizes with the real HW, we only get the data
back with the next command.
This makes sense in a weird kind of way.
I still don't have an explanation why both 'usb-handoff' and 'acpi=off'
help, I'd expect only the first to, but it might be related to the SCI
interrupt routing which isn't done when 'acpi=off'. Just a wild guess.
SCI interrupt routing?  I have tried with pci=routeirq and that hasn't 
helped either.  IRQ balancing perhaps?

I don't like the interrupt message, I'll check why it's enabled so
early. It may have a good reason to, as well. Other than that, it looks
very much OK.
That was with usb-handoff.  It also resulted in the black screen of 
bios-death upon reboot though :).

So as with acpi=off, we get a correct return.  Now that usb is 
mentioned, I think either myself or Sebastian has mentioned that the 
keyboard does not work unless USB1.1 support is compiled in.  Another 
clue possibly?

Compiling USB 1.1 support does the very same thing as specifying
usb-handoff on the command like - tells the BIOS to keep its hands off
the USB _and_ PS/2 controllers.
I'm missing something, I have USB1.1 compiled in, then why does the 
touchpad not work if it does the very same thing as usb-handoff?

Another question - would it be usefull at all to see what happens if the 
AUX_LOOP test is never performed but only AUX_TEST?  Or does AUX_TEST 
rely on the fact that AUX_LOOP must first fail/timeout somehow?
No. You can use AUX_TEST event before AUX_LOOP. But I expect it to fail
similarly when BIOS is active.
That is correct.  It fails with timeout.  This for me confirms the fact 
that it is responding one command too late. aka, we send a command, it 
times out, we send another, it sends the result of the first.

Right, any new (or variations of existing ones) theories that I can try 
out to make this touchpad work correctly?  I can simply hack out the 
test for the touchpad but that doesn't solve the problem for others.

Jaco
--
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

[Trever L. Adams]

For the record, this has nothing to do with my crash. Mine still crashes
all the time if I try to save a new document.

Trever

On Sat, 2005-01-29 at 14:25 -0500, Jon Smirl wrote:
> On Sat, 29 Jan 2005 13:02:51 +, Richard Hughes <[EMAIL PROTECTED]> wrote:
> > On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
> > > Note, that strace glxgears gives exactly the same output, going from 0 to
> > > 14 and then seg-faulting, so it's *not just a oo problem*.
> > 
> > I know it's bad to answer your own post, but here goes.
> > 
> > I changed my /etc/udev/permissions.d/50-udev.permissions config to read:
> > 
> > dri/*:root:root:0666
> > 
> > changing it from
> > 
> > dri/*:root:root:0660
> > 
> > And oowriter and glxgears work from bootup. Shall I file a bug with udev?
> 
> Your user ID needs to belong to group DRI.
> 
--
Legal Warning: Anyone sending me unsolicited/commercial email WILL be
charged a $100 proof-reading fee. See US Code Title 47,
Sec.227(a)(2)(B), Sec.227(b)(1)(C) and Sec.227(b)(3)(C).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] mark the mcd cdrom driver as BROKEN

[Adrian Bunk]

On Sat, Jan 29, 2005 at 06:22:55PM +0100, Jean Delvare wrote:
> Hi Adrian,
> 
> > The mcd driver drives only very old hardware (some single and double 
> > speed CD drives that were connected either via the soundcard or a 
> > special ISA card), and the mcdx driver offers more functionality for
> > the  same hardware.
> > 
> > My plan is to mark MCD as broken in 2.6.11 and if noone complains 
> > completely remove this driver some time later.
> > (...)
> > -   depends on CD_NO_IDESCSI
> > +   depends on CD_NO_IDESCSI && BROKEN
> 
> Shouldn't we introduce a DEPRECATED option for use in cases like this
> one?

We could.

We could also list MCD in Documentation/feature-removal-schedule.txt 
first.

But in this case I doubt it makes any difference.

This driver is for hardware where I doubt many users exist today, and it 
should have been removed nearly ten years ago when the better mcdx 
driver for the same now-obsolete hardware entered the kernel.

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

Re: Possible bug in keyboard.c (2.6.10)

[Vojtech Pavlik]

On Sat, Jan 29, 2005 at 04:50:55AM +, Al Viro wrote:

> > I'm very sorry about the locking, but the thing grew up in times of
> > kernel 2.0, which didn't require any locking. There are a few possible
> 
> Incorrect.  You have blocking allocations in critical areas and they
> required locking all way back.

Ok. I see a problem where input_register_device() calls input handler
connect methods, which do kmalloc(). This would be bad even on 2.0.

Anything else? I believe the ->open()/->release() methods are still
protected.

> > races with device registration/unregistration, and it's on my list to
> > fix that, however under normal operation there shouldn't be any need for
> > locks, as there are no complex structures built that'd become
> > inconsistent. 
> 
> Um-hm...  Vojtech, meet USB mouse; USB mouse, meet Vojtech.  Now watch
> a disconnect and reconnect happening when luser suddenly gets overexcited
> and jerks the wrong hand a bit too hard while browsing the most profitable
> sort of website...

I know. As I said, this is a problem I know about, and will be fixed. I
was mainly interested whether anyone sees further problems in scenarios
which don't include device addition/removal.

We already fixed this in serio, and input and gameport are next in the
list.

> > If you find scenarios which will lead to trouble in the event delivery
> > system, please tell me, and I'll try to fix that as soon as possible.
> 
> See above.  Devices appearing and disappearing *are* normal.  

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

Re: AT keyboard dead on 2.6

[Vojtech Pavlik]

On Fri, Jan 28, 2005 at 09:46:41AM -0500, Dmitry Torokhov wrote:
> On Fri, 28 Jan 2005 15:31:21 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 25, 2005 at 08:37:34PM +0100, Wiktor wrote:
> > > Hi,
> > >
> > > here you are gzip-ed dmesg from booting 2.6.8.1 - i've been playing
> > > keyboard while booting, maybe interrupt reports will help you. also my
> > > .config part follows:
> > > CONFIG_INPUT=y
> > > CONFIG_INPUT_MOUSEDEV=y
> > > CONFIG_SOUND_GAMEPORT=y
> > > CONFIG_SERIO=y
> > > CONFIG_SERIO_I8042=y
> > > CONFIG_INPUT_KEYBOARD=y
> > > CONFIG_KEYBOARD_ATKBD=y
> > > no modules or other built-ins. maybe it is some simple way to fall back
> > > to old handling mechanism? in my system most of programs (i mean
> > > x-server) uses hardware directly (what means uses /dev/ttyS0 as mouse
> > > device). i'm grateful for any help.
> > 
> > This dmesg looks like the keyboard works perfectly OK. Do new lines
> > appear in dmesg when you press keys while the system is running?
> >
> 
> It does no report any IDs but ACKs GETID command. Not very nice...
 
Very old AT keyboards can do that.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] document atkbd.softraw

[Vojtech Pavlik]

On Sat, Jan 29, 2005 at 12:23:15AM +0100, [EMAIL PROTECTED] wrote:

> Document atkbd.softraw (and shorten a few long lines nearby).

Thanks, applied.

> --- a/Documentation/kernel-parameters.txt 2004-12-29 03:39:42.0 
> +0100
> +++ b/Documentation/kernel-parameters.txt 2005-01-29 00:21:07.0 
> +0100
> @@ -222,15 +222,19 @@ running once the system is up.
>  
>   atascsi=[HW,SCSI] Atari SCSI
>  
> - atkbd.extra=[HW] Enable extra LEDs and keys on IBM RapidAccess, 
> EzKey
> - and similar keyboards
> + atkbd.extra=[HW] Enable extra LEDs and keys on IBM RapidAccess,
> + EzKey and similar keyboards
>  
>   atkbd.reset=[HW] Reset keyboard during initialization
>  
>   atkbd.set=  [HW] Select keyboard code set 
>   Format:  (2 = AT (default) 3 = PS/2)
>  
> - atkbd.scroll=   [HW] Enable scroll wheel on MS Office and similar 
> keyboards
> + atkbd.scroll=   [HW] Enable scroll wheel on MS Office and similar
> + keyboards
> +
> + atkbd.softraw=  [HW] Choose between synthetic and real raw mode
> + Format:  (0 = real, 1 = synthetic (default))
>   
>   atkbd.softrepeat=
>   [HW] Use software keyboard repeat
> 

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

Re: USB HID events and Microsoft wheel mouse

[Vojtech Pavlik]

On Fri, Jan 28, 2005 at 11:02:52PM -0500, Jon Smirl wrote:

> Something changed in the Linus BK kernel in the last few days so that
> I get "drivers/usb/input/hid-input.c: event field not found" in dmesg
> everytime I move my MS Wheel mouse. Any ideas on how to get rid of
> this?
> 
> The events are EV_MISC:
> type 4 code 4 value 65585
> type 4 code 4 value 65584
> type 4 code 4 value 589825

The events are raw HID usages, and they're intentional. The "event field
not found" is a bug, sorry, and I'll fix it ASAP.

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

Re: Possible bug in keyboard.c (2.6.10)

[Vojtech Pavlik]

On Sat, Jan 29, 2005 at 01:11:08PM +0100, Roman Zippel wrote:

> > I'm very sorry about the locking, but the thing grew up in times of
> > kernel 2.0, which didn't require any locking. There are a few possible
> > races with device registration/unregistration, and it's on my list to
> > fix that, however under normal operation there shouldn't be any need for
> > locks, as there are no complex structures built that'd become
> > inconsistent. 
> 
> I wouldn't say that there is no need for that, but that these events are 
> rather rare, but it can happen.

Sorry, I meant to say that of course locking is needed for protecting
the device and handler lists, but that the event delivery path itself
is in my opinion safe, and that there is no need to eg. lock
input_event() against concurrent use by different callers.

> Unfortunately the lack of locking is all 
> over the keyboard/vc/tty layer. It would have been nice if input had 
> introduced some improvement here.
> This seriously becomes a problem as soon we want to allow the user to 
> dynamically attach/detach devices.

I agree, and I plan to fix the locking at least in input and keyboard.
How far it'll go into vc/tty I can't promise.`

> > > I tried to find a few times to find any discussion about the input
> > > layer design, but I couldn't find anything.
> > 
> > You have to search in very old archives. There was quite a lot of it,
> > and it was going off on a lot of tangents. In the end, I just wrote it.
> 
> How old and which archives?

1999 I think, some discussion was on L-K, the rest on
[EMAIL PROTECTED], which, unfortunately, doesn't have
a web-based archive.

> > > - a single input device structure for all types: this structure is quite 
> > > big, where most of its contents is irrelevant for most devices.
> > 
> > I actually think this is a big plus. 
> > 
> > Real word devices cannot be confined into predefined structures, as
> > hardware develops, mice get more buttons, wheels, force feedback, 
> 
> That doesn't necessarilly mean we have to pack everything into a single 
> structure. E.g. we present pci boards with multiple functions as multiple 
> devices, the same can be done for input devices. More important is that 
> kernel drivers only expect a certain class of devices, e.g. the keyboard 
> driver only needs the keyboard related parts and would also allow us to 
> add more keyboard specific callbacks instead of sending events.

The USB HID devices often are crossing the device type boundaries. A
keyboard with a few mouse buttons, for example. Yes, we could split it,
but I really doubt the gain.

The GGI people went the way of predefined device types ...

> > The intention here is that we have two types of events, input and
> > output. Most events are input (REL, ABS, ...), while some travel the
> > opposite direction. For simplicity, the interface is the same -
> > input_event(), which then, based on the event type decides where to
> > forward it - whether up or down the stream (or both, where other users
> > of the device may be interested in the change).
> 
> This is rather a hint that the abstraction is wrong, e.g. why not send 
> sound events to the pckbd _handler_? A device should just send input 
> events and handlers handle them and with sysfs we should actually rename 
> the latter to input_drivers (it's less confusing this way).

You imply that the atkbd module would register itself both as an input
device, and as an input handler? That's quite an interesting idea I
haven't thought about before.

But then all the handlers also have to register themselves as devices,
for generating the LED and Sound events. Probably we then could get rid
of the handlers altogether and have devices only, which would both send
and receive events.

It would work, but to me this looks even more confusing. 

> Some other problems I have with the current design:
> - unified keyboard/mouse device: one rather annoying problem, which is 
> neither solved by the input system or the linuxconsole patches, is that 
> one can't use keyboards with different mappings (e.g. german and english 
> is what I have here).

The unified mouse device was planned for backward compatibility only,
unfortunately it stuck, since for userspace that was the easiest way to
deal with hotplug.

The single keyboard similarly was the easiest way how to plug the input
into keyboard.c. James Simmons was working on the vc part of the code,
but it never made it there. It sort of lives in the linuxconsole
patches, but was never really finished either.

> I have a patch which makes the keymap data more 
> dynamic and assigns it to keyboard device,

Cool! How do you load the keymaps for the specific devices? How do you
assign the devices to vcs? Can a user have per-vc keymaps?

> which has the positive side effect that all keyboards don't have to
> send the same keycodes anymore (and we don't have to break all the
> keyboards anymore which don't use AT style keycodes).

Well, I think the fac

Re: AT keyboard dead on 2.6

[Vojtech Pavlik]

On Fri, Jan 28, 2005 at 08:39:42PM +0100, Wiktor wrote:

> Hi, IT WORKED!
> 
> >Please try i8042.noaux=1. You say you're using a serial mouse in your
> >other e-mail, so the system may not have an AUX port yet the kernel
> >thinks it does. This may cause the keyboard to stop responding.
> 
> command line "linux-new init=/bin/bash i8042.noaux=1 atkbd.reset=1" 
> booted 2.6.8.1 kernel with working keyboard. reset succeded. If AUX port 
> is what not-keen-on-hardware people call PS/2 port, the problem is 
> solved. my mainboard has damaged PS/2 port - it is detected but it does 
> NOT work. Thanks for paying attention.
 
Yes, the AUX port and PS/2 mouse port are two names for the same thing.

Do you still need atkbd.reset=1?

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

Re: Possible bug in keyboard.c (2.6.10)

[Vojtech Pavlik]

On Fri, Jan 28, 2005 at 10:59:39PM +0100, Andries Brouwer wrote:
> On Fri, Jan 28, 2005 at 12:10:05PM +0100, Vojtech Pavlik wrote:
> 
> > And, btw, raw mode in 2.6 is not badly broken. It works as it is
> > intended to. If you want the 2.4 behavior on x86, you just need to
> > specify "atkbd.softraw=0" on the kernel command line.
> 
> Thanks for pointing that out - I should have read patch-2.6.9 more
> carefully. I'll add that to the setkeycodes.8 man page.
> 
> Nevertheless I disagree a bit. "raw mode" is by definition the mode
> where scan codes are passed unmodified to user space.
> So before 2.6.9 this was just broken, and since 2.6.9 it is broken
> by default but there is a boot option to make it work.

The problem is that users wouldn't be happy if I passed USB usage codes
when they enable raw mode with an USB keyboard.

The expectation is that 'it will work'.

Because of that, the 'softraw=0' option _only_ works for AT and PS/2
keyboards, with any other keyboard type it has no effect.

> What is the reason that you do not make this the default?

To have all keyboard types behave the same, instead of having a single
exception, although I admit that the exception would be for the most
common case.

> The current default is really messy and confusing, especially
> when people have to map keys using setkeycodes.

The emulated rawmode is there mainly for X. If it weren't for X, I
wouldn't bother generating rawmode for keyboards other than PS/2, and
for PS/2 I'd have kept the true raw data there.

However, on 2.6, where you can have more than one keyboard, it'd be
better to use the EVIOCSKEYCODE ioctl on the event device instead of the
KDSKEYCODE ioctl on the console, as the later only changes the first
found keyboard.

Also, if setkeycodes used the event device, it'd get the raw scancodes
easily, as they're embedded in the event stream together with the
keycodes.

I'd hoped someone of the lineak/.../... multimedia key people will make
such an utility, but now I see that what one doesn't do himself, doesn't
happen. I will write it, possibly as a patch to setkeycodes.

> BTW, now that I read the corresponding code:
> 
> if (atkbd_softrepeat)
> atkbd_softraw = 1;
> 
> if (!atkbd_softrepeat) {
> atkbd->dev.rep[REP_DELAY] = 250;
> atkbd->dev.rep[REP_PERIOD] = 33;
> } else atkbd_softraw = 1;
> 
> The "else" part is superfluous.

It indeed is. It's been removed, too.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/16] New set of input patches

[Vojtech Pavlik]

On Thu, Jan 27, 2005 at 01:18:55PM -0500, Dmitry Torokhov wrote:
> On Thu, 27 Jan 2005 17:36:05 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > On Thu, Jan 27, 2005 at 05:15:18PM +0100, Vojtech Pavlik wrote:
> > 
> > > OK. I'll go through them, and apply as appropriate. I still need to wrap
> > > my mind around the start() and stop() methods and see the necessity. I
> > > still think a variable in the serio struct, only accessed by the serio.c
> > > core driver itself (and never by the port driver) that'd cause all
> > > serio_interrupt() calls to be ignored until set in the asynchronous port
> > > registration would be well enough.
> > 
> > I've read he start() and stop() code, and I came to the conclusion
> > again that we don't need them as serio port driver methods. i8042 uses
> > them to set the exists variable only and uses that variable _solely_ for
> > the purpose of skipping calls to serio_interrupt(), serio_cleanup() and
> > serio_unregister().
> > 
> > By instead checking a member of the serio struct in these functions, and
> > doing nothing if not set, we achieve the same goal, without adding extra
> > cruft to the interface, making it allowed to call these serio functions
> > on a non-registered or half-registered serio struct, with the effect
> > being defined to nothing.
> > 
> 
> No, you can not peek into serio structure from a driver, not when it
> was dynamically allocated and can be gone at any time. Please consider
> the following screnario when shutting down 8042 when you have a MUX
> with several ports:
> 
> The rough call sequence is:
> i8042_exit
>   serio_unregister_port
>  driver->disconnect
> serio_close
>i8042->close
>  free(serio)
> 
> We need to keep interrupts passed to serio core until serio_close is
> completed so device properly ACKs/responds to cleanup commands.
> Additionally, in i8042 close we do not free IRQ until last port is
> unregistered nor we disable the port because we want to support
> hotplugging. If interrupt comes after port was freed but before
> serio_unregister_port has returned i8042_interrupt will call
> serio_interrupt for port that was just free()ed. Special flag in serio
> will not help because you need to know that port pointer is valid. You
> could try pinning the port in memory buy taking a refernce but then
> asynchronous unregister is not possible and it is needed in some
> cases.
> 
> I think that having these 2 interface functions helps clearly define
> these sequence points when port can/can not be used, simplifies logic
> and alerts driver authors of this potential problem.
 
You're right. I forgot that serio isn't anymore tied to the driver and
can cease to exist on its own asynchronously. However, I'm still not
sure whether it's worth it. We might as well simply drop the unregister
call in i8042_open for AUX completely and forget about asynchronous
unregisters and use normal refcounting. As far as grep knows, it's the
only user.

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

[PATCH 0/3] - Three more input fixes for 2.6.11

[Vojtech Pavlik]

Hi!

The previous set introduced one bug, mostly harmless, but pretty
annoying - the hid-input driver fills the logs with the 'event field not
found' message. I'm sorry for that, I just tested that the patch does
what it should and didn't check the logs.

The last of these three patches fixes that.

The first fixes the MUX disabling routine in i8042 to really do
something on reboot, and the second patch from Andries adds a
documentation entry for atkbd.softraw.

Please include them before 2.6.11, as the bug described above would
cause a lot of e-mails to be sent to me.

The patches are available at

bk://kernel.bkbits.net/vojtech/for-linus

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

Re: OpenOffice crashes due to incorrect access permissions on /dev/dri/card*

[Jon Smirl]

On Sat, 29 Jan 2005 13:02:51 +, Richard Hughes <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
> > Note, that strace glxgears gives exactly the same output, going from 0 to
> > 14 and then seg-faulting, so it's *not just a oo problem*.
> 
> I know it's bad to answer your own post, but here goes.
> 
> I changed my /etc/udev/permissions.d/50-udev.permissions config to read:
> 
> dri/*:root:root:0666
> 
> changing it from
> 
> dri/*:root:root:0660
> 
> And oowriter and glxgears work from bootup. Shall I file a bug with udev?

Your user ID needs to belong to group DRI.

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

Re: [PATCH] Restrict procfs permissions

[Rene Scharfe]

Al Viro wrote:
On Sat, Jan 29, 2005 at 03:45:42AM +0100, Rene Scharfe wrote:
The patch is inspired by the /proc restriction parts of the
GrSecurity patch.  The main difference is the ability to configure
the restrictions dynamically.  You can change the umask setting by
running
# mount -o remount,umask=007 /proc
Testing has been *very* light so far -- it compiles and boots.
Patch is against 2.6.11-rc2-bk6.
Comments are very welcome.

It leaves already existing inodes with whatever mode they used to
have.
I said "configure the restrictions dynamically" but I meant "doesn't
need a recompile to change settings".  I expect the umask to be
specified in /etc/fstab and rarely changed in a running system.  With
that in mind I think the patch is useful as-is, especially because it's
so small.  But I agree, that thing is a dirty hack. :]
_IF_ you want to do that sort of things, do it right - add
->permission() that would apply that umask before checks and if you
want it to be seen in results of stat(2) - add ->gettattr() and do
the same there.
Aww, that sounds expensive.  My favourite solution would be to only 
allow the umask to be changed at mount time, not when remounting.

Calling parse_options from proc_fill_super, only and not from 
proc_remount does not help very much because proc_fill_super is only 
called at boot (or proc module load time).  Is there another way?

While we are here: how would one change the uid or gid parameter? With a 
built-in proc fs the mount -a -t proc in the init scripts only results 
in a proc_remount call which (in mainline) doesn't bother looking at 
parameters at all.  The same is true for a unmount, mount sequence.

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

[PATCH 3/3] Fix 'event field not found' message filling logs

[Vojtech Pavlik]

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus

===

[EMAIL PROTECTED], 2005-01-29 13:09:24+01:00, [EMAIL PROTECTED]
  input: Ignore non-LED events in hid-input hidinput_event(). This gets rid
 of the "event field not found" message caused by EV_MSC type events.
  
  Signed-off-by: Vojtech Pavlik <[EMAIL PROTECTED]>


 hid-input.c |3 +++
 1 files changed, 3 insertions(+)

===

diff -Nru a/drivers/usb/input/hid-input.c b/drivers/usb/input/hid-input.c
--- a/drivers/usb/input/hid-input.c 2005-01-29 17:37:11 +01:00
+++ b/drivers/usb/input/hid-input.c 2005-01-29 17:37:11 +01:00
@@ -492,6 +492,9 @@
if (type == EV_FF)
return hid_ff_event(hid, dev, type, code, value);
 
+   if (type != EV_LED)
+   return -1;
+
if ((offset = hid_find_field(hid, type, code, &field)) == -1) {
warn("event field not found");
return -1;

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

Re: AT keyboard dead on 2.6

[Vojtech Pavlik]

On Fri, Jan 28, 2005 at 09:22:20PM +0100, Wiktor wrote:
> Hi,
> 
> >We do test AUX port and your port appears to be perfectly functional
> >from the kernel point of view - it porperly responds to AUX_LOOP
> >commands, does not claim to support MUX mode and KBC properly sets
> >status register when asked to disable interface...
> 
> ok, but how AUX block KBD port? if procesor-interface works, it 
> shouldn't disturb communication in any way!

The AUX and KBD ports share the same processor interface. If the AUX
port is enabled, and somehow keeps the interface for itself, then the
keyboard wouldn't work.

For some reason, however, the keyboard is recognized, which means it
_can_ communicate with the kernel. I don't understand why it doesn't, at
the moment.

> how it is possible that 
> tests do not detect broken down port? 

The kernel issues the AUX_TEST command, which instructs the port
controller to test whether the port is OK. And the controller returns
with "Yes, it is."

> if kernel enables it in some way 
> (when disabling port from command line, KBD works ok), it should be 
> detected that AUX does not work correctly and lock it somehow? 

Remember, it's the keyboard that doesn't work in that case. How the
kernel should know the AUX port is the cause, and how it should discern
that from the user not typing?

> can it be 
> etermined by analyzing data flow? 

No.

> or maybe tests are not enought good, 
> maybe some corelations when using both KBD and AUX exist and are not 
> tested? as my keyboard works now, i'm not keen on solving this, but to 
> make the world better and dominate it, some "runtime hardware failures 
> handling" could be added.
 
We're pretty happy when it works on functional hardware at the moment.

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

How do I get a list of all pids on 2.6? (what's wrong with this code)

[Jed Brazos]

Hi,

  I'm trying to list all of the tasks and their
children. (Im using a 2.6.5-7 kernel)

  The code below does not list all of the pids as
compared to the /proc entries.

  Why does the following code not list all of the
active pids in the system?

please cc this id.

  ---




void list_pids(void)
{
struct task_struct *tp;
struct list_head   *_p;
struct list_head   *_n;
struct task_struct *p;


read_lock(&tasklist_lock);
for (tp = &init_task;  (tp = next_task(tp)) !=
&init_task; ) {
 printk("[parent]  pid =%d\n" ,tp->pid );
 list_for_each_safe(_p,_n, &tp->children ){
 p = list_entry(_p,struct
task_struct,sibling);
 printk("   [child]  pid =%d   \n", p->pid
);

 }
}
read_unlock(&tasklist_lock);
 return ;
}






__ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

patch - ftdi_sio.c floods my logs with "write request of 0 bytes"

[Elias Oltmanns]

Hi there,

unfortunately, I'm everything else but a developer, so please be a bit
patient with me.

As indicated by the subject, I got annoyed by the error message
mentioned flooding my log files. Comparing ftdi_sio.c to some of the
other usb->serial converter drivers, I decided to apply the following
small patch:


--- linux-2.6.10.orig/drivers/usb/serial/ftdi_sio.c 2004-12-24 
21:35:24.0 +
+++ linux-2.6.10/drivers/usb/serial/ftdi_sio.c  2005-01-29 17:10:11.0 
+
@@ -1518,7 +1518,7 @@
dbg("%s port %d, %d bytes", __FUNCTION__, port->number, count);
 
if (count == 0) {
-   err("write request of 0 bytes");
+   dbg("%s - write request of 0 bytes", __FUNCTION__);
return 0;
}



It solved my problem but I can't judge, of course, whether the use of
err() instead of dbg() is justified or even common in this place, as,
for instance, ftdi_sio.c is considered experimental. Therefore I would
be grateful to get a short response.

Thank you very much in advance,

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

2.6.10-ac11 announcement?

[Ralf Hildebrandt]

Where is the 2.6.10-ac11 announcement?

-- 
Ralf Hildebrandt (i.A. des IT-Zentrum)  [EMAIL PROTECTED]
Charite - Universitätsmedizin BerlinTel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-BerlinFax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] Document the atkbd.softraw module parameter.

[Vojtech Pavlik]

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus

===

[EMAIL PROTECTED], 2005-01-29 12:27:56+01:00, [EMAIL PROTECTED]
  input: Document the atkbd.softraw module parameter.
  
  From: Andries Brouwer <[EMAIL PROTECTED]>
  Signed-off-by: Vojtech Pavlik <[EMAIL PROTECTED]>


 kernel-parameters.txt |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

===

diff -Nru a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt   2005-01-29 17:37:19 +01:00
+++ b/Documentation/kernel-parameters.txt   2005-01-29 17:37:19 +01:00
@@ -226,15 +226,19 @@
 
atascsi=[HW,SCSI] Atari SCSI
 
-   atkbd.extra=[HW] Enable extra LEDs and keys on IBM RapidAccess, 
EzKey
-   and similar keyboards
+   atkbd.extra=[HW] Enable extra LEDs and keys on IBM RapidAccess,
+   EzKey and similar keyboards
 
atkbd.reset=[HW] Reset keyboard during initialization
 
atkbd.set=  [HW] Select keyboard code set 
Format:  (2 = AT (default) 3 = PS/2)
 
-   atkbd.scroll=   [HW] Enable scroll wheel on MS Office and similar 
keyboards
+   atkbd.scroll=   [HW] Enable scroll wheel on MS Office and similar
+   keyboards
+
+   atkbd.softraw=  [HW] Choose between synthetic and real raw mode
+   Format:  (0 = real, 1 = synthetic (default))

atkbd.softrepeat=
[HW] Use software keyboard repeat

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

Re: i8042 access timings

[Vojtech Pavlik]

On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote:
> Vojtech Pavlik wrote:
> >On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote:
> >
> >
> >>>So what _might_ happen is that we write the command, and then 
> >>>i8042_wait_write() thinks that there is space to write the data 
> >>>immediately, and writes the data, but now the data got lost because the 
> >>>buffer was busy.
> >>
> >>Hmm - I just answered the same post and concluded that I didnt understand,
> >>so you have progressed further. I considered the same possibility,
> >>but the data was not lost since we read it again later.
> >>Only the ready flag was lost.
> >
> > 
> >What I believe is happening is that we're talking to SMM emulation of
> >the i8042, which doesn't have a clue about these commands, while the
> >underlying real hardware implementation does. And because of that they
> >disagree on what should happen when the command is issued, and since the
> >SMM emulation lazily synchronizes with the real HW, we only get the data
> >back with the next command.
> >
> >I still don't have an explanation why both 'usb-handoff' and 'acpi=off'
> >help, I'd expect only the first to, but it might be related to the SCI
> >interrupt routing which isn't done when 'acpi=off'. Just a wild guess.
> >
> 
> Ok, I'm not too clued up with recent hardware and the BIOS programming 
> that goes with it (being a system admin/application programmer), what 
> exactly is usb-handoff?

usb-handoff is a kernel option that enables a PCI quirk routine that
takes the USB controller out of BIOS's hands. Until that is done (the
linux USB drivers also do it, only later), the BIOS owns the USB
controller and tries to emulate a PS/2 mouse and keyboard for systems
which can't handle USB.

>  acpi=off obviously just turns all acpi support 
> in the kernel off. 

Indeed.

> SCI is also a new abbreviation I haven't seen 
> before.

System Configuration Interrupt. In addition to SMI (System Management
Interrupt), these are two interrupts the BIOS uses to do its job behind
the operating system's back.

>  Whilst I've seen SMM before, I'm not sure what it stands for (I 

SMM is System Management Mode. It's a special mode of the CPU, which is
entered when a SMI is triggered by some event, like an port write trap
in the case of the emulated PS/2 mouse. 

Using SMM the BIOS can emulate any device it wishes to, and the OS will
think it's real. It's an even more privileged mode than what the OS runs
in.

> assume it's something to do with simulation of legacy devices for older 
> operating systems)?

It also does thermal monitoring, often is used for turning the backlight
off on notebooks, and handling various magic Fn- key combinations.

> From the kernel-parameters documentation:
> 
> usb-handoff [HW] Enably early USB BIOS -> OS handoff
> 
> I guess this means the OS takes over control of the USB devices at an 
> earlier stage than usual - possibly before ACPI gets initialised? 

Before the i8042 keyboard driver gets initialized. That's the important
part, because the handoff stops the BIOS from emulating a PS/2 mouse,
and thus blocking access to the real PS/2 mouse controller.

> I'm 
> unable to determine much from looking at drivers/pci/quirks.c (which is 
> where the usb-handoff parameter is defined).
> 
> usb-handoff=1 does however also fix the problem.  Ok.  This makes it 
> even more confusing (and probably more complicated).  The appropriate 
> section from dmesg that shows that it is working correctly:
> 
> i8042_init()
> ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
> ACPI: PS/2 Mouse Controller [MSE0] at irq 12
> i8042_controller_init()
> i8042_flush()
> drivers/input/serio/i8042.c: 20 -> i8042 (command) [4]
> drivers/input/serio/i8042.c: 47 <- i8042 (return) [4]
> drivers/input/serio/i8042.c: 60 -> i8042 (command) [4]
> drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [4]
> i8042_check_aux()
> drivers/input/serio/i8042.c: Interrupt 12, without any data [8]
> i8042_flush()
> drivers/input/serio/i8042.c: d3 -> i8042 (command) [13]
> drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13]
> drivers/input/serio/i8042.c: a5 <- i8042 (return) [13]
> i8042_check_aux:  passed

I don't like the interrupt message, I'll check why it's enabled so
early. It may have a good reason to, as well. Other than that, it looks
very much OK.

> So as with acpi=off, we get a correct return.  Now that usb is 
> mentioned, I think either myself or Sebastian has mentioned that the 
> keyboard does not work unless USB1.1 support is compiled in.  Another 
> clue possibly?

Compiling USB 1.1 support does the very same thing as specifying
usb-handoff on the command like - tells the BIOS to keep its hands off
the USB _and_ PS/2 controllers.

> Another question - would it be usefull at all to see what happens if the 
> AUX_LOOP test is never performed but only AUX_TEST?  Or does AUX_TEST 
> rely on the fact that AUX_LOOP must first fail/timeout somehow?

No. You can 

[PATCH 1/3] Fix MUX mode disabling.

[Vojtech Pavlik]

You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus

===

[EMAIL PROTECTED], 2005-01-28 21:11:52+01:00, [EMAIL PROTECTED]
  input: Fix MUX mode disabling.
  
  Signed-off-by: Vojtech Pavlik <[EMAIL PROTECTED]>


 i8042.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

===

diff -Nru a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c   2005-01-29 17:37:27 +01:00
+++ b/drivers/input/serio/i8042.c   2005-01-29 17:37:27 +01:00
@@ -482,7 +482,7 @@
if (i8042_command(¶m, I8042_CMD_AUX_LOOP) || param != 0x0f)
return -1;
param = mode ? 0x56 : 0xf6;
-   if (i8042_command(¶m, I8042_CMD_AUX_LOOP) || param != 0xa9)
+   if (i8042_command(¶m, I8042_CMD_AUX_LOOP) || param != (mode ? 0xa9 
: 0x09))
return -1;
param = mode ? 0xa4 : 0xa5;
if (i8042_command(¶m, I8042_CMD_AUX_LOOP) || param == (mode ? 0x5b 
: 0x5a))
@@ -787,7 +787,8 @@
  * Disable MUX mode if present.
  */
 
-   i8042_set_mux_mode(0, NULL);
+   if (i8042_mux_present)
+   i8042_set_mux_mode(0, NULL);
 
 /*
  * Restore the original control register setting.

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

Re: AT keyboard dead on 2.6

[Vojtech Pavlik]

On Fri, Jan 28, 2005 at 08:49:03PM +0100, Wiktor wrote:
> Hi,
> 
> >Could you please try editing drivers/input/serio/i8042.c and add
> >udelay(20) before and after calls to i8042_write_data() in
> >i8042_kbd_write() and i8042_command().
> 
> of course i could, will it make kernel not detect smoked AUX port? 
> (problem is solved by i8042.noaux=1 cause my hardware has smoked PS/2 
> port) i would rather think about testing devices before assuming thet 
> work and trying to use them (maybe not as standard kernel feature, but 
> it would be nice stuff for people with self-built machines where not 
> everything works). Thanks for your help
 
Well, the kernel tests the AUX port and it seemed OK, that's the
problem. Unfortunately it's not always possible to detect whether
there's a problem with some device.

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

Re: AT keyboard dead on 2.6

[Vojtech Pavlik]

On Fri, Jan 28, 2005 at 08:22:32PM +0100, Wiktor wrote:
> Hi,
> 
> >This dmesg looks like the keyboard works perfectly OK. Do new lines
> >appear in dmesg when you press keys while the system is running?
> 
> .no? no, they don't. i've new dmesg for you - it reports 
> timeouts while trying to perform keyboard reset (by atkbd.reset=1). 
> after detection pressing any keys has absolutley no effect. maybe it's 
> some timeout-violation?

It still looks OK. It seems to be a very ancient keyboard. Can you try with
a newer one? That'd tell us whether it's the controller or the keyboard
that is giving problems.

What keyboard model is it? What machine?

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