date:20071217

On Mon, 10 Dec 2007 15:09:43 -0500 trash can [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 I have tolerated this problem for a year and do not post to this list in
 haste. I have posted on forums and searched the community over the past
 year.

Your report is welcome - thanks.  Let's cc the IDE/sata development list.

 I have looked at the list archive on gossamer-threads.com for
 solutions. With Fedora Core 6 unsupported (the last kernel for which my
 zip drive worked), it is time for my last attempt at a solution. Please
 CC: any response as I have not joined the list. I have compiled a
 kernel-debug RPM and can run this if its output would help. Thank you
 for any time you might devote to this problem.
 
 motherboard: MSI P965 Platinum/Intel P965 Express Chipset Based (MS-7238
 series)
 Fedora 8 : kernel 2.6.23.1-42.fc8
 Iomega Zip drive internal Model Z100ATAPI
 
 lspci
 03:00.0 SATA controller: JMicron Technologies, Inc. JMB361 AHCI/IDE (rev 02)
 03:00.1 IDE interface: JMicron Technologies, Inc. JMB361 AHCI/IDE (rev 02)
 
 # lsmod | grep ata
 pata_jmicron8257  0
 ata_generic 8901  0
 ata_piix   16709  0
 libata 99633  4 ahci,pata_jmicron,ata_generic,ata_piix
 scsi_mod  119757  4 sr_mod,sg,libata,sd_mod
 
 I have recently changed the BIOS setting for the SATA#1 Controller from
 [IDE] to [AHCI] with no effect. I assume AHCI is correct?
 
 Text below attached as text.txt for readability.
 from dmesg:
 libata version 2.21 loaded.
 device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED]
 PCI: Enabling device :03:00.1 ( - 0001)
 ACPI: PCI Interrupt :03:00.1[B] - GSI 17 (level, low) - IRQ 17
 PCI: Setting latency timer of device :03:00.1 to 64
 scsi0 : pata_jmicron
 scsi1 : pata_jmicron
 ata1: PATA max UDMA/100 cmd 0x0001cc00 ctl 0x0001c882 bmdma 0x0001c400 irq 17
 ata2: PATA max UDMA/100 cmd 0x0001c800 ctl 0x0001c482 bmdma 0x0001c408 irq 17
 ata1.00: ATAPI: LITE-ON DVDRW SOHW-1693S, KS0B, max UDMA/66
 ata1.01: ATAPI: IOMEGA  ZIP 100   ATAPI, 05.H, max MWDMA1, CDB intr
 ata1.00: configured for UDMA/66
 ata1.01: configured for MWDMA1
 scsi 0:0:0:0: CD-ROMLITE-ON  DVDRW SOHW-1693S KS0B PQ: 0 ANSI: 5
 scsi 0:0:1:0: Direct-Access IOMEGA   ZIP 100  05.H PQ: 0 ANSI: 5
 sd 0:0:1:0: [sda] 196608 512-byte hardware sectors (101 MB)
 sd 0:0:1:0: [sda] Write Protect is off
 sd 0:0:1:0: [sda] Mode Sense: 00 40 00 00
 sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
 DPO or FUA
 sd 0:0:1:0: [sda] 196608 512-byte hardware sectors (101 MB)
 sd 0:0:1:0: [sda] Write Protect is off
 sd 0:0:1:0: [sda] Mode Sense: 00 40 00 00
 sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
 DPO or FUA
  sda:6sd 0:0:1:0: [sda] Result: hostbyte=DID_OK 
 driverbyte=DRIVER_SENSE,SUGGEST_OK
 sd 0:0:1:0: [sda] Sense Key : Hardware Error [current]
 sd 0:0:1:0: [sda] Add. Sense: Scsi parity error
 end_request: I/O error, dev sda, sector 0
 Buffer I/O error on device sda, logical block 0
 
 If a disk is inserted into the drive (/var/log/messages)
 Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Spinning up 
 disk.5sd 0:0:1:0: [sda] Spinning up diskready
 Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] 196608 512-byte hardware 
 sectors (101 MB)
 Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Write Protect is off
 Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Write cache: enabled, 
 read cache: enabled, doesn't support DPO or FUA
 Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] 196608 512-byte hardware 
 sectors (101 MB)
 Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Write Protect is off
 Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Write cache: enabled, 
 read cache: enabled, doesn't support DPO or FUA
 Dec 10 14:22:53 localhost kernel:  sda:6sd 0:0:1:0: [sda] Result: 
 hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
 Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Sense Key : Hardware 
 Error [current]
 Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Add. Sense: Scsi parity 
 error
 Dec 10 14:22:53 localhost kernel: end_request: I/O error, dev sda, sector 0
 Dec 10 14:22:53 localhost kernel: printk: 42 messages suppressed.
 Dec 10 14:22:53 localhost kernel: Buffer I/O error on device sda, logical 
 block 0
 

So which is the most recent kernel version which worked OK?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] max3100 driver

2007-12-17 Thread Jiri Slaby

On 12/17/2007 09:55 AM, chri wrote:
 On Dec 17, 2007 9:45 AM, Jiri Slaby [EMAIL PROTECTED] wrote:
 You probably wanted to unregister it after _all_ cards are removed, not after
 each...

 
 Hi,
 
 thanks you are right. I haven't noticed this since spi devices are not
 hot-pluggable so I could remove them only with rmmod (and so all of
 them toghether). Anyway the code I sent is ugly, I will correct and
 resend.

Won't bind/unbind in sysfs help you?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

2007-12-17 Thread Michael Tokarev

Michael Tokarev wrote:
 Kay Sievers wrote:
 On Mon, 2007-12-17 at 08:29 +0300, Michael Tokarev wrote:
 []
 How to distinguish char devices from block devices in sysfs?
 Is the only way to read a symlink `subsystem' in the device
 directory?
 By its subsystem value (block), from the symlink, from the environment,
 or from $1.
 
 Environment and $1 comes as arguments for hotplug helper, not
 when scanning /sys/.

By the way, that's one of reasons I asked about useful content
in uevent files (but failed to provide a patch so far ;).
In 2.6.23, those files ARE readable finally, but doesn't
contain much info yet.

/mjt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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/1] IPN: Inter Process Networking

2007-12-17 Thread Renzo Davoli

Inter Process Networking (PATCH):

This patch adds a new address family for inter process communication.
AF_IPN: inter process networking, i.e. multipoint,
multicast/broadcast communication among processes (and networks).

Contents of this document:

1. What is IPN?
2. Why IPN?
2.1 Why IPN instead of IP Multicast?
2.2 Why IPN instead of AF_NETLINK?
3. How?

We've read all the comments in the previous thread about IPN and we've
tried to answer.

1. WHAT IS IPN?
---

IPN is a new address family designed for one-to-many, many-to-many and 
peer-to-peer communication among processes.
Berkeley sockets have been designed for client-server or point-to-point
communication; AF_UNIX does not support multicast/broadcast. AF_IPN
does, in a simple, efficient but extensible way.
IPN is an Inter Process Communication paradigm where all the processes
appear as they were connected by a networking bus.

On IPN, processes can interoperate using real networking protocols 
(e.g. ethernet) but also using application defined protocols (maybe 
just sending ascii strings, video or audio frames, etc).
IPN provides networking (in the broaden definition you can imagine) to
the processes. Processes can be ethernet nodes, run their own TCP-IP stacks
if they like (e.g. virtual machines), mount ATAonEthernet disks, etc.etc.

IPN networks can be interconnected with real networks or IPN networks
running on different computers can interoperate (can be connected by
virtual cables).

IPN is part of the Virtual Square Project (vde, lwipv6, view-os, 
umview/kmview, see wiki.virtualsquare.org).

2. WHY IPN?
---
Many applications can benefit from IPN.
First of all VDE (Virtual Distributed Ethernet): one service of IPN is a
kernel implementation of VDE.
IPN can be useful for applications where one or some processes feed their
data (*any kind* of data, not only networking-related messages) to several
consuming processes (maybe joining the stream at run time). IPN sockets
can be also connected to tap (tuntap) like interfaces or to real interfaces
(like brctl addif).
There are specific ioctls to define a tap interface or grab an existing
one.

Several existing services could be implemented (and often could have extended
features) on the top of IPN:
 - kernel Ethernet bridging
 - TUN/TAP
 - MACVLAN

IPN could be used (IMHO) to provide multicast services to processes.
Audio frames or video frames could be multiplexed such that multiple
applications can use them. I think that something like Jack can be
implemented on the top of IPN. Something like a VideoJack can
provide video frames to several applications: e.g. the same image from a
camera can be viewed by xawtv, recorded and sent to a streaming service.
IPN sockets can be used wherever there is the idea of broadcasting channel 
i.e. where processes can join (and leave) the information flow at
runtime. IPN can be seen as publish and subscribe.
Different delivery policies can be defined as IPN protocols (loaded 
as submodules of ipn.ko).
For instance, an ethernet switch is a policy (kvde_switch.ko: packets
are unicast delivered if the MAC address is already in the switching
hash table), we are designing an extendended switch, full of interesting
features like our userland vde_switch (with vlan/fst/manamement etc..),
and a layer3 switch, but other policies can be defined to implement the
specific requirements of other services. I feel that there is no limits
to creativity about multicast services for processes.  Userspace
services (like vde) do exist, but IPN provides a faster and unified
support.

2.1 Why IPN instead of IP Multicast?

 - IPN seems to be faster than IP Multicast. (see my message to LKML
   of Dec 06).
 - IPN provides file system permission to access the communication medium,
   and it uses the file system for naming.
 - IPN does not need any tunneling or packet encapsulation, it works as a
   layer 1 virtual network.
 - IPN protocols (implemented by kernel submodules) provide forwarding
   policies: the set of receipients for each messages is computed from the
   contents of the message itself.
   Ethernet virtual switches or other routing rules for any kind of data
   can be implemented as IPN protocols.

2.2 Why IPN instead of AF_NETLINK?
--
 - Netlink has been designed for user to kernel communication.
 - Netlink has many missing features to provide services similar to IPN.
 - Currently multicast seems to be allowed for root only. Access control
   should be added completely.
 - Netlink interface for user processes is not very immediate (libnl has
   been developed as a higher level solution to that).
 - Netlink already seems to suffer from overpopulation:
   NETLINK_GENERIC has been added for simplified netlink usage but it
   adds yet another header and rules to be followed.
 - Netlinks is quite rigid as for message delivery guarantees: unicast
   implies lossless

INITIO scsi driver fails to work properly

2007-12-17 Thread Filippos Papadopoulos

Hi,
I have got an INITIO 9100 UW SCSI Controller with an IBM
IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
Currently i have SUSE 10.1 (Kernel 2.6.16).

I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
OpenSUSE 11.0 Alpha 0  (kernel 2.6.24-rc4) but although the initio
driver
gets loaded during the installation process, yast reports that no hard
disk is found. I believe that this isnt a bug in suse's yast but a
problem
in the initio scsi driver because i also tried to install Fedora 8
(kernel 2.6.23) with the same problem.
I have seen the relevant thread Conflict when loading initio driver
and i suppose that the initio driver isnt fixed yet.
I can help testing the new patches in the initio driver if someone is
interested.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

2007-12-17 Thread Michael Buesch

On Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote:
 On Dec 17, 2007 1:52 AM, Larry Finger [EMAIL PROTECTED] wrote:
 
  One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the 
  former always used a fixed
  rate; whereas mac80211 tries to adjust the bit rate according to the 
  transmission conditions.
  Perhaps it isn't working quite right in your case because of some 
  peculiarity of your AP. IIRC, you
  have an 802.11b AP. If so, you will get the same bit speed behavior for 
  mac80211 as for bcdm43xx by
  issuing a 'sudo iwconfig eth1 rate 11M' command.
 
 I don't know what happened before, but after a reboot, I can't repeat
 the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
 didn't move the laptop, or the ap, the only thing I can think of that
 might have changed is the noise level. FWIW, link quality is
 consistently the same or better with b43.
 
 Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and
 quickly scales to 11 Mb/s, but I tried setting it manually anyway and
 didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as
 1 Mb/s and the download speed was the same with all three (around
 30-40 kB/s).

Are you working with wireless-2.6's #everything branch?

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

Re: init_timer_deferrable conversion

2007-12-17 Thread Eric Dumazet

On Sun, 16 Dec 2007 22:00:23 -0500 (EST)
Parag Warudkar [EMAIL PROTECTED] wrote:

 In my quest to get the wake-ups from idle per second down to bare minimum, 
 I noticed 3 places in the kernel that could benefit from 
 using init_timer_deferrable() instead of init_timer() -
 
 a) drivers/net/sky2.c - watchdog_timer. This was showing up high on 
 Powertop's list of things that cause routine wakeups from idle. After 
 converting to init_timer_deferrable() the wakeups went down and this one 
 no longer shows up in powertop's list. 25% reduction.
 
 b) kernel/time/clocksource.c - watchdog_timer - same story as sky2.c
 
 c) net/core/neighbour.c - gc_timer - Most benefit from deferrable timer.

neigh_periodic_timer() is actually doing almost nothing per round, since it
looks only one slot of hash table. We could probably convert it to a
workqueue and scan whole table at once.

 
 I am running a kernel with above changes and haven't noticed any immediate 
 problems and the wakeups-from-idle have gone down from 5-7 to mere 1-2 per 
 second.
 
 Is there any reason not to make the above timers deferrable - corner 
 cases, other side effects? If not then I will submit a patch.
 
 Thanks
 
 Parag
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

2007-12-17 Thread mvtodevnull

On Dec 17, 2007 4:49 AM, Michael Buesch [EMAIL PROTECTED] wrote:

 Are you working with wireless-2.6's #everything branch?

I've been working with vanilla wireless-2.6, but I've also tried the
everything branch as well as other trees. Just for good measure, I
just rebuilt the everything branch and it shows the same behavior.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] [patch 1/2] add non_init_kernel_text_address

2007-12-17 Thread Srinivasa Ds

Changing regular_kernel_text_address() to persistent_kernel_text_address().

Since __init functions are discarded and its memory freed once
initialization completes, It would be better if we enable kprobes
to refuse probing __init functions. The attached patchset will do
that.

This patch creates persistent_kernel_text_address() to identify
non_init text area.


Signed-off-by: Srinivasa DS [EMAIL PROTECTED]
Signed-off-by: Ananth N Mavinakayanahalli [EMAIL PROTECTED]



---
 include/linux/kernel.h |2 ++
 kernel/extable.c   |   16 +++-
 2 files changed, 17 insertions(+), 1 deletion(-)

Index: linux-2.6.24-rc5-mm1/include/linux/kernel.h
===
--- linux-2.6.24-rc5-mm1.orig/include/linux/kernel.h
+++ linux-2.6.24-rc5-mm1/include/linux/kernel.h
@@ -169,6 +169,8 @@ extern unsigned long long memparse(char 
 extern int core_kernel_text(unsigned long addr);
 extern int __kernel_text_address(unsigned long addr);
 extern int kernel_text_address(unsigned long addr);
+extern int persistent_kernel_text_address(unsigned long addr);
+extern int persistent_core_kernel_text(unsigned long addr);
 struct pid;
 extern struct pid *session_of_pgrp(struct pid *pgrp);
 
Index: linux-2.6.24-rc5-mm1/kernel/extable.c
===
--- linux-2.6.24-rc5-mm1.orig/kernel/extable.c
+++ linux-2.6.24-rc5-mm1/kernel/extable.c
@@ -40,11 +40,18 @@ const struct exception_table_entry *sear
return e;
 }
 
-int core_kernel_text(unsigned long addr)
+int persistent_core_kernel_text(unsigned long addr)
 {
if (addr = (unsigned long)_stext 
addr = (unsigned long)_etext)
return 1;
+   return 0;
+}
+
+int core_kernel_text(unsigned long addr)
+{
+   if (persistent_core_kernel_text(addr))
+   return 1;
 
if (addr = (unsigned long)_sinittext 
addr = (unsigned long)_einittext)
@@ -65,3 +72,10 @@ int kernel_text_address(unsigned long ad
return 1;
return module_text_address(addr) != NULL;
 }
+
+int persistent_kernel_text_address(unsigned long addr)
+{
+   if (persistent_core_kernel_text(addr))
+   return 1;
+   return module_text_address(addr) != NULL;
+}



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

[RFC] [patch 2/2] Refuse kprobe insertion on __init section code

2007-12-17 Thread Srinivasa Ds

This patch makes use of persistent_kernel_text_address() to avoid
probing __init functions.

Signed-off-by: Srinivasa DS [EMAIL PROTECTED]
Signed-off-by: Ananth N Mavinakayanahalli [EMAIL PROTECTED]




---
 kernel/kprobes.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.24-rc5-mm1/kernel/kprobes.c
===
--- linux-2.6.24-rc5-mm1.orig/kernel/kprobes.c
+++ linux-2.6.24-rc5-mm1/kernel/kprobes.c
@@ -520,7 +520,7 @@ static int __kprobes __register_kprobe(s
return -EINVAL;
p-addr = (kprobe_opcode_t *)(((char *)p-addr)+ p-offset);
 
-   if (!kernel_text_address((unsigned long) p-addr) ||
+   if (!persistent_kernel_text_address((unsigned long) p-addr) ||
in_kprobes_functions((unsigned long) p-addr))
return -EINVAL;
 
@@ -662,7 +662,7 @@ int __kprobes register_jprobe(struct jpr
 {
unsigned long addr = arch_deref_entry_point(jp-entry);
 
-   if (!kernel_text_address(addr))
+   if (!persistent_kernel_text_address(addr))
return -EINVAL;
 
/* Todo: Verify probepoint is a function entry point */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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/1] IPN: Inter Process Networking

2007-12-17 Thread david


On Mon, 17 Dec 2007, Renzo Davoli wrote:


Inter Process Networking (PATCH):

1. WHAT IS IPN?
---

IPN is a new address family designed for one-to-many, many-to-many and
peer-to-peer communication among processes.
Berkeley sockets have been designed for client-server or point-to-point
communication; AF_UNIX does not support multicast/broadcast. AF_IPN
does, in a simple, efficient but extensible way.
IPN is an Inter Process Communication paradigm where all the processes
appear as they were connected by a networking bus.

On IPN, processes can interoperate using real networking protocols
(e.g. ethernet) but also using application defined protocols (maybe
just sending ascii strings, video or audio frames, etc).
IPN provides networking (in the broaden definition you can imagine) to
the processes. Processes can be ethernet nodes, run their own TCP-IP stacks
if they like (e.g. virtual machines), mount ATAonEthernet disks, etc.etc.

IPN networks can be interconnected with real networks or IPN networks
running on different computers can interoperate (can be connected by
virtual cables).

IPN is part of the Virtual Square Project (vde, lwipv6, view-os,
umview/kmview, see wiki.virtualsquare.org).


other then the fact that this is bi-directional, how is this better then 
using pipes and splice?


wouldn't it be better to just add the ability for multiple writers to send 
to the same pipe, and then have all of them splice into the output of that 
pipe? this would give the same data-agnostic communication that you are 
looking for, and with the minor detail that software would have to filter 
out messages that they send, would appear to meet all the goals you are 
looking at, useing existing kernel features that are designed to be very 
high performance.


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

Re: Could not set non-blocking flag with 2.6.24-rc5

On Fri, 14 Dec 2007 01:45:39 +0100 Rafael J. Wysocki [EMAIL PROTECTED] 
wrote:

 On Thursday, 13 of December 2007, Tino Keitel wrote:
  Hi folks,
  
  I often build Debian packages inside a chroot. Today I discovered a
  failure during an aptitude update, which is a command to download new
  package lists for the package management. In strace, the lines around
  the failure look like this:
  
  99% [Working]) = 14 14
  [pid  5986] select(6, [3 4 5], [], NULL, {0, 50}) = 0 (Timeout)
  [pid  5986] gettimeofday({1197576353, 670510}, NULL) = 0
  [pid  5986] rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
  [pid  5986] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  99% [Working]) = 14 14
  [pid  5986] select(6, [3 4 5], [], NULL, {0, 50}) = 0 (Timeout)
  [pid  5986] gettimeofday({1197576354, 173902}, NULL) = 0
  [pid  5986] rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
  [pid  5986] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  99% [Working]) = 14 14
  [pid  5986] select(6, [3 4 5], [], NULL, {0, 50} unfinished ...
  [pid  5988] ... select resumed )  = 1 (in [3], left {105, 0})
  [pid  5988] read(3, , 56559)  = 0
  [pid  5988] fcntl64(-1, F_GETFL)= -1 EBADF (Bad file
  descriptor)
  [pid  5988] fcntl64(-1, F_SETFL,
  O_ACCMODE|O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC|O_APPEND|O_SYNC|O_ASYNC|O_DIRECT|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|0xfff8003c)
  = -1 EBADF (Bad file descriptor)
  [pid  5988] write(2, ..., 41FATAL - Could not set non-blocking flag
  ) = 41
  [pid  5988] write(2, ..., 19Bad file descriptor) = 19
  [pid  5988] write(2, ..., 1
  )  = 1
  [pid  5988] exit_group(100) = ?
  Process 5988 detached
  
  This happened with a kernel after 2.6.24-rc5
  (4af75653031c6d454b4ace47c1536f0d2e727e3e). I rebooted into 2.6.23.8
  and it worked. Now I rebooted into 2.6.24-rc5 again and was able to
  reproduce the failure, so it looks like a kernel issue to me.
 
 Yes, it does.
 
 I'm not sure who to forward it to, though.  Andrew, can you help, please?

hm, I missed this email, sorry.

That application is passing an fd of -1 into the kernel's fcntl64().  Could
be an application bug, could be a kernel change which triggered an
application bug, could be a kernel bug.

Can we see more of the strace output please?  Let's see if we can find
where the application got that -1 from.

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

Re: RFC: remove __read_mostly

On Fri, 14 Dec 2007 01:33:45 +0100 Andi Kleen [EMAIL PROTECTED] wrote:

 Kyle McMartin [EMAIL PROTECTED] writes:
 
  I'd bet, in the __read_mostly case at least, that there's no
  improvement in almost all cases.
 
 I bet you're wrong. Cache line behaviour is critical, much more
 than pipeline behaviour (which unlikely affects). That is because
 if you eat a cache miss it gets really expensive, which e.g.
 a mispredicted jump is relatively cheap in comparison. We're talking
 one or more orders of magnitude.

So...  once we've moved all read-mostly variables into __read_mostly, what
is left behind in bss?

All the write-often variables.  All optimally packed together to nicely
maximise cacheline sharing.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

2007-12-17 Thread mvtodevnull

If this is a mac80211 related problem, then other systems connecting
to the same ap and using mac80211 would also be affected? Like I said
earlier, there are five machines connecting to this ap, and I just
realized one of them has a ralink card that uses the rt2x00 driver,
which I believe is mac80211. That system doesn't have this problem,
which leads me to believe it may not be mac80211 after all, although I
wouldn't rule it out.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PAT 64b: Basic PAT implementation

2007-12-17 Thread Daniel J Blueman

On 14 Dec, 00:50, Andi Kleen [EMAIL PROTECTED] wrote:
  +void __cpuinit pat_init(void)
  +{
  +  /* Set PWT+PCD to Write-Combining. All other bits stay the same */
  +  if (cpu_has_pat) {

 All the old CPUs (PPro etc.) with known PAT bugs need to clear this flag
 now in their CPU init functions. It is fine to be aggressive there
 because these old systems have lived so long without PAT they can do
 so forever. So perhaps it's best to just white list it only for newer
 CPUs on the Intel side at least.

 Another problem is that there are some popular modules (ATI, Nvidia for once)
 who reprogram the PAT registers on their own, likely different. Need some way 
 to detect
 that case I guess, otherwise lots of users will see strange malfunctions.
 Maybe recheck after module load?

This may not be as big problem as thought, since sane and at least one
vendor driver (Quadrics QsNetII) searches the PAT slots for a WC entry
- where this has already been setup by the kernel, it'll use the right
one.

  +   |||
  + 000 WB default
  + 010 UC_MINUS   _PAGE_PCD
  + 011 WC _PAGE_WC
  + PAT bit unused */
  +  pat = PAT(0,WB) | PAT(1,WT) | PAT(2,UC_MINUS) | PAT(3,WC) |
  +PAT(4,WB) | PAT(5,WT) | PAT(6,UC_MINUS) | PAT(7,WC);
  +  rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
  +  wrmsrl(MSR_IA32_CR_PAT, pat);
  +  __flush_tlb_all();
  +  asm volatile(wbinvd);

 Have you double checked this is the full procedure from the manual? iirc there
 were some steps missing.

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

Re: [RFC] move free page back to MIGRATE_MOVABLE?

2007-12-17 Thread Mel Gorman

On (13/12/07 13:19), Shaohua Li didst pronounce:
 pages are MIGRATE_MOVABLE initially, and fallback to other types. If the
 pages are freed, I wonder why not move them back to MIGRATE_MOVABLE.

Because there is no need, if a MIGRATE_MOVABLE allocation needs more pages,
they will be acquired during fallback which always steals the largest
block. Lets say that a MIGRATE_UNMOVABLE block is freed and it is larger
than pageblock_order. The next MIGRATE_MOVABLE allocation will find it during
fallback if necessary.

 This, for example, can help memory remove.
 

I don't see how. When hot-removing, MIGRATE_MOVABLE blocks are considered
possible to remove but they are also considered movable if the pages are free.

 Thanks,
 Shaohua 
 
 Index: linux/mm/page_alloc.c
 ===
 --- linux.orig/mm/page_alloc.c2007-12-13 11:44:36.0 +0800
 +++ linux/mm/page_alloc.c 2007-12-13 12:04:59.0 +0800
 @@ -386,6 +386,9 @@ static inline int page_is_buddy(struct p
   return 0;
  }
  
 +int move_freepages(struct zone *zone,
 + struct page *start_page, struct page *end_page,
 + int migratetype);
  /*
   * Freeing function for a buddy system allocator.
   *
 @@ -446,6 +449,17 @@ static inline void __free_one_page(struc
   list_add(page-lru,
   zone-free_area[order].free_list[migratetype]);
   zone-free_area[order].nr_free++;
 +
 + if (order = pageblock_order  migratetype != MIGRATE_MOVABLE) {
 + struct page *tmp = page;
 +
 + move_freepages(zone, page, page + (1  order) - 1, 
 MIGRATE_MOVABLE);
 +

This is unnecessary and affects a commonly used path. If a MOVABLE allocation
needs more pages later, it will find the large free block during fallback.

 + while (tmp  page + (1  order)) {
 + set_pageblock_migratetype(tmp, MIGRATE_MOVABLE);
 + tmp += pageblock_nr_pages;
 + }
 + }
  }
  
  static inline int free_pages_check(struct page *page)
 

-- 
Mel Gorman
Part-time Phd Student  Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc5-mm1 compile failure: usbhid_lookup_quirk

On Sat, 15 Dec 2007 19:50:40 +0100 jurriaan [EMAIL PROTECTED] wrote:

   MODPOST 196 modules
   ERROR: usbhid_lookup_quirk [drivers/hid/usbhid/usbmouse.ko]
   undefined!
   ERROR: usbhid_lookup_quirk [drivers/hid/usbhid/usbkbd.ko] undefined!
   make[1]: *** [__modpost] Error 1
   make: *** [modules] Error 2
 
 The problem was fixed by defining CONFIG_USB_HID=m - but I think that
 should happen automatically if it is necessary.
 
 .config was created by running make oldconfig against 2.6.23-rc8-mm2:

Thanks.  That's coming out of git-hid.patch.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ATA bus error with external hd on esata

On Sat, 15 Dec 2007 21:10:47 +0100 Zsolt Barat [EMAIL PROTECTED] wrote:

 Zsolt Barat schrieb:
  hi list,

Let's cc the IDE development list.

  i just bought a MyBook called external HD with a fixed enclosure, from
  WD. Connected to the SATA port i constantly get ATA bus error messages
  in the kernel log. Is this a known issue?
 
  /var/log/messages:
  Dec 15 18:37:53 proto1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0
  action 0x2
  Dec 15 18:37:53 proto1 ata2.00: irq_stat 0x4001
  Dec 15 18:37:53 proto1 ata2.00: cmd 35/00:e0:a7:d2:01/00:01:33:00:00/e0
  tag 0 cdb 0x0 data 245760 out
  Dec 15 18:37:53 proto1 res 51/84:00:86:d4:01/00:00:33:00:00/e0 Emask
  0x10 (ATA bus error)
  Dec 15 18:37:54 proto1 ata2: soft resetting port
  Dec 15 18:37:54 proto1 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl
  310)
  Dec 15 18:37:54 proto1 ata2.00: configured for UDMA/33
  Dec 15 18:37:54 proto1 ata2: EH complete
  Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] 976773168 512-byte hardware
  sectors (500108 MB)
  Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Write Protect is off
  Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
  Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Write cache: enabled, read
  cache: enabled, doesn't support DPO or FUA
  Dec 15 18:38:15 proto1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0
  action 0x2
  Dec 15 18:38:15 proto1 ata2.00: irq_stat 0x4001
  Dec 15 18:38:15 proto1 ata2.00: cmd 35/00:80:bf:09:14/00:01:33:00:00/e0
  tag 0 cdb 0x0 data 196608 out
  Dec 15 18:38:15 proto1 res 51/84:00:3e:0b:14/00:00:33:00:00/e0 Emask
  0x10 (ATA bus error)
  Dec 15 18:38:15 proto1 ata2: soft resetting port
  Dec 15 18:38:15 proto1 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl
  310)
  Dec 15 18:38:15 proto1 ata2.00: configured for UDMA/33
  Dec 15 18:38:15 proto1 ata2: EH complete
  Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] 976773168 512-byte hardware
  sectors (500108 MB)
  Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Write Protect is off
  Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
  Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Write cache: enabled, read
  cache: enabled, doesn't support DPO or FUA
 
  lspci:
  00:00.0 Host bridge: ATI Technologies Inc Unknown device 7910
  00:01.0 PCI bridge: ATI Technologies Inc Unknown device 7912
  00:07.0 PCI bridge: ATI Technologies Inc Unknown device 7917
  00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
  00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
  00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
  00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
  00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
  00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
  00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
  00:14.0 SMBus: ATI Technologies Inc SB600 SMBus (rev 13)
  00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
  00:14.2 Audio device: ATI Technologies Inc SB600 Azalia
  00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
  00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge
  00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
  HyperTransport Technology Configuration
  00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
  Address Map
  00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
  DRAM Controller
  00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
  Miscellaneous Control
  01:05.0 VGA compatible controller: ATI Technologies Inc Radeon X1200 Series
  01:05.2 Audio device: ATI Technologies Inc Radeon X1200 Series Audio
  Controller
  02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
  RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
  03:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
  Controller (rev c0)
 
  thanks and best regards
 
  zsolt

 sorry, kernel version is: 2.6.23-gentoo-r1
 

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

Re: RFC: remove __read_mostly

2007-12-17 Thread Eric Dumazet

On Mon, 17 Dec 2007 02:33:39 -0800
Andrew Morton [EMAIL PROTECTED] wrote:

 On Fri, 14 Dec 2007 01:33:45 +0100 Andi Kleen [EMAIL PROTECTED] wrote:
 
  Kyle McMartin [EMAIL PROTECTED] writes:
  
   I'd bet, in the __read_mostly case at least, that there's no
   improvement in almost all cases.
  
  I bet you're wrong. Cache line behaviour is critical, much more
  than pipeline behaviour (which unlikely affects). That is because
  if you eat a cache miss it gets really expensive, which e.g.
  a mispredicted jump is relatively cheap in comparison. We're talking
  one or more orders of magnitude.
 
 So...  once we've moved all read-mostly variables into __read_mostly, what
 is left behind in bss?
 
 All the write-often variables.  All optimally packed together to nicely
 maximise cacheline sharing.

This is why it's important to group related variables together, so that they 
share
same cacheline.

Random example : vmlist_lock  vmlist

Currently in two separate cache lines (not that important since vmlist is
 so big that one extra cache line access is not measurable)

Other possibilities are :

1) to make sure that really critical hot spots are alone 
(they eventually waste a full cacheline, even if only 4 bytes are in use)

2) Or they are mixed with seldom used data. (One cache line contains one
critical object + other mostly_unused data). This kind of mixing
is really hard to do without a special linker.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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/1] IPN: Inter Process Networking

2007-12-17 Thread Ludovico Gardenghi

On Mon, Dec 17, 2007 at 03:31:48AM -0800, [EMAIL PROTECTED] wrote:

 wouldn't it be better to just add the ability for multiple writers to send 
 to the same pipe, and then have all of them splice into the output of that 
 pipe? this would give the same data-agnostic communication that you are 
 looking for, and with the minor detail that software would have to filter 
 out messages that they send, would appear to meet all the goals you are 
 looking at, useing existing kernel features that are designed to be very 
 high performance.

Being able to define both filtering policies (think of a virtual
ethernet layer 2 switch, for instance. We have situations where dozens
or hundreds of virtual cables are connected to the same switch, it would
be much, much slower if you had to awake all the user processes for each
single non-broadcast ethernet frame, and send them useless data) and
delivery guarantees (lossless vs best-effort delivery) are not minor
details in our opinion.

We might have added a level2 virtual ethernet switch at kernel
level, but it seemed to specific. With a minor effort we have split the
dumb bus (IPN) and the ability to process specific structured data
with specific policies (sub-modules as kvde_switch).

We surely may adapt existing features (AF_UNIX, or pipes) but they offer
a quite established interface and semantics and we think it should be
better to add a new family. This would prevent from breaking what
already exists and leaving more freedom in defining the new family
according to needs.

As for ptrace vs utrace: ptrace has been designed for debugging; trying
to bend it to be fit for virtualization is likely to end up in an
intricated interface and implementation. utrace has been designed in a
much more general way. You can implement ptrace over utrace, but you can
use utrace also for virtualization in a cleaner, simpler and more
efficient way. Why not?

Ludovico
-- 
[EMAIL PROTECTED]#acheronte (irc.freenode.net) ICQ: 64483080
GPG ID: 07F89BB8  Jabber: [EMAIL PROTECTED] Yahoo: gardenghelle
-- This is signature nr. 3556
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 V2] ipwireless_cs driver for 4G PC Card

2007-12-17 Thread Jiri Kosina

[ CC list trimmed ] 

On Wed, 12 Dec 2007, David Sterba wrote:

 Changelog:
 * files moved to ipwireless/, ipwireless_cs_ stripped from filenames
 * _cs stripped from driver name
 * kmalloc checks
 * sync irq during shutdown
 * removed /proc code, converted to module params
 
 When merged, please drop ipwireless_cs.git tree from -mm and
 include the patch instead.
 
 Regards,
 David Sterba
 
 Rewieved-by: Jiri Slaby [EMAIL PROTECTED]
 Signed-off-by: Ben Martel [EMAIL PROTECTED]
 Signed-off-by: Stephen Blackheath [EMAIL PROTECTED]
 Signed-off-by: David Sterba [EMAIL PROTECTED]
 Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
 ---
  MAINTAINERS |8 
  drivers/char/pcmcia/Kconfig |9 
  drivers/char/pcmcia/Makefile|2 
  drivers/char/pcmcia/ipwireless/Makefile |   10 
  drivers/char/pcmcia/ipwireless/hardware.c   | 1784 
 
  drivers/char/pcmcia/ipwireless/hardware.h   |   63 
  drivers/char/pcmcia/ipwireless/main.c   |  496 ++
  drivers/char/pcmcia/ipwireless/main.h   |   70 
  drivers/char/pcmcia/ipwireless/network.c|  513 ++
  drivers/char/pcmcia/ipwireless/network.h|   54 
  drivers/char/pcmcia/ipwireless/setup_protocol.h |  108 +
  drivers/char/pcmcia/ipwireless/tty.c|  687 +
  drivers/char/pcmcia/ipwireless/tty.h|   48 
  13 files changed, 3852 insertions(+)

Andrew, what is your position on merging this into your 2.6.25 queue 
please? David has fixed all the issues that came up during review, so it 
seems to be that it's time for the driver to be merged during the upcoming 
merge window.

If you take it, I am perfectly fine with you dropping the 
ipwireless_cs git tree from -mm lineup.

Thanks,

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.


* Rene Herman [EMAIL PROTECTED] wrote:

 On 16-12-07 16:22, Ingo Molnar wrote:

 looks good to me. Could you please also provide three more controls that i 
 suggested earlier:

  - a boot option enabling/disabling the udelay based code
  - a .config method of enabling/disabling the udelay based code
  - a sysctl to toggle it

 if we want to clean this all up we'll need as many controls as possible.

 This version does the boot and the .config option but not the sysctl. 
 It makes for clumsy code and I don't believe it provides for much 
 added value as soon as you have the boot option. I am moreover not 
 completely confident about things such as paravirt liking the 
 possibility of the native_io_delay being changed out from under them 
 at unpredictable times.

 So how is this? Also fixes a few problems with the previous version.

thanks Rene! I've added your patch to x86.git. I changed a few things 
ontop of it, see the additional changelog and delta patch below.

Ingo



- add the io_delay=none method
- make each method selectable from the kernel config
- simplify the delay code a bit by getting rid of an indirect function call
- add the /proc/sys/kernel/io_delay_type sysctl
- change 'standard' and 'alternate' to 0x80 and 0xed
- make the io delay config not depend on CONFIG_DEBUG_KERNEL

---
 Documentation/kernel-parameters.txt |   12 ++--
 arch/x86/Kconfig.debug  |   79 +--
 arch/x86/kernel/io_delay.c  |  103 
 include/asm-x86/io_32.h |2 
 include/asm-x86/io_64.h |2 
 kernel/sysctl.c |9 +++
 6 files changed, 138 insertions(+), 69 deletions(-)

Index: linux-x86.q/Documentation/kernel-parameters.txt
===
--- linux-x86.q.orig/Documentation/kernel-parameters.txt
+++ linux-x86.q/Documentation/kernel-parameters.txt
@@ -786,12 +786,14 @@ and is between 256 and 4096 characters. 
then look in the higher range.
 
io_delay=   [X86-32,X86-64] I/O delay method
-   standard
-   Standard port 0x80 delay
-   alternate
-   Alternate port 0xed delay
+   0x80
+   Standard port 0x80 based delay
+   0xed
+   Alternate port 0xed based delay (needed on some systems)
udelay
-   Simple two microsecond delay
+   Simple two microseconds delay
+   none
+   No delay
 
io7=[HW] IO7 for Marvel based alpha systems
See comment before marvel_specify_io7 in
Index: linux-x86.q/arch/x86/Kconfig.debug
===
--- linux-x86.q.orig/arch/x86/Kconfig.debug
+++ linux-x86.q/arch/x86/Kconfig.debug
@@ -112,13 +112,78 @@ config IOMMU_LEAK
  Add a simple leak tracer to the IOMMU code. This is useful when you
  are debugging a buggy device driver that leaks IOMMU mappings.
 
-config UDELAY_IO_DELAY
-   bool Delay I/O through udelay instead of outb
-   depends on DEBUG_KERNEL
+#
+# IO delay types:
+#
+
+config IO_DELAY_TYPE_0X80
+   int
+   default 0
+
+config IO_DELAY_TYPE_0XED
+   int
+   default 1
+
+config IO_DELAY_TYPE_UDELAY
+   int
+   default 2
+
+config IO_DELAY_TYPE_NONE
+   int
+   default 3
+
+choice
+   prompt IO delay type
+   default IO_DELAY_0X80
+
+config IO_DELAY_0X80
+   bool port 0x80 based port-IO delay [recommended]
+   help
+ This is the traditional Linux IO delay used for in/out_p.
+ It is the most tested hence safest selection here.
+
+config IO_DELAY_0XED
+   bool port 0xed based port-IO delay
help
- Make inb_p/outb_p use udelay() based delays by default. Please note
- that udelay() does not have the same bus-level side-effects that
- the normal outb based delay does meaning this could cause drivers
- to change behaviour and/or bugs to surface.
+ Use port 0xed as the IO delay. This frees up port 0x80 which is
+ often used as a hardware-debug port.
+
+config IO_DELAY_UDELAY
+   bool udelay based port-IO delay
+   help
+ Use udelay(2) as the IO delay method. This provides the delay
+ while not having any side-effect on the IO port space.
+
+config IO_DELAY_NONE
+   bool no port-IO delay
+   help
+ No port-IO delay. Will break on old boxes that require port-IO
+ delay for certain operations. Should work on most new machines.
+
+endchoice
+
+if IO_DELAY_0X80
+config DEFAULT_IO_DELAY_TYPE
+   int
+   default IO_DELAY_TYPE_0X80
+endif
+
+if IO_DELAY_0XED
+config DEFAULT_IO_DELAY_TYPE
+   int
+   default IO_DELAY_TYPE_0XED
+endif
+
+if IO_DELAY_UDELAY

sata_mv not working with a RocketRaid 2220

2007-12-17 Thread Jean-Louis Dupond


Added CC to linux-ide

 Originele bericht 
Onderwerp:  sata_mv not working with a RocketRaid 2220
Datum:  Mon, 17 Dec 2007 00:15:30 +0100
Van:Jean-Louis Dupond [EMAIL PROTECTED]
Aan:linux-kernel@vger.kernel.org



Hello,

I'm trying to get my HighPoint RocketRaid Controller working with the 
sata_mv drivers.

But something is not working correctly :(

Kernel version 2.6.23.11 (also tried 2.6.24-rc5 with same results)
Controller in lspci: Marvell Technology Group Ltd. MV88SX6081 8-port 
SATA II PCI-X Controller (rev 07)


 1.
Dec 16 22:44:29 localhost kernel: sata_mv :05:08.0: Gen-II 32
slots 8 ports SCSI mode IRQ via INTx
 2.
Dec 16 22:44:29 localhost kernel: scsi4 : sata_mv
 3.
Dec 16 22:44:29 localhost kernel: scsi5 : sata_mv
 4.
Dec 16 22:44:29 localhost kernel: scsi6 : sata_mv
 5.
Dec 16 22:44:29 localhost kernel: scsi7 : sata_mv
 6.
Dec 16 22:44:29 localhost kernel: scsi8 : sata_mv
 7.
Dec 16 22:44:29 localhost kernel: scsi9 : sata_mv
 8.
Dec 16 22:44:29 localhost kernel: scsi10 : sata_mv
 9.
Dec 16 22:44:29 localhost kernel: scsi11 : sata_mv
10.
Dec 16 22:44:29 localhost kernel: ata5: SATA max UDMA/133 cmd
0x ctl 0xc20010122120 bmdma 0x
irq 16
11.
Dec 16 22:44:29 localhost kernel: ata6: SATA max UDMA/133 cmd
0x ctl 0xc20010124120 bmdma 0x
irq 16
12.
Dec 16 22:44:29 localhost kernel: ata7: SATA max UDMA/133 cmd
0x ctl 0xc20010126120 bmdma 0x
irq 16
13.
Dec 16 22:44:29 localhost kernel: ata8: SATA max UDMA/133 cmd
0x ctl 0xc20010128120 bmdma 0x
irq 16
14.
Dec 16 22:44:29 localhost kernel: ata9: SATA max UDMA/133 cmd
0x ctl 0xc20010132120 bmdma 0x
irq 16
15.
Dec 16 22:44:29 localhost kernel: ata10: SATA max UDMA/133 cmd
0x ctl 0xc20010134120 bmdma 0x
irq 16
16.
Dec 16 22:44:29 localhost kernel: ata11: SATA max UDMA/133 cmd
0x ctl 0xc20010136120 bmdma 0x
irq 16
17.
Dec 16 22:44:29 localhost kernel: ata12: SATA max UDMA/133 cmd
0x ctl 0xc20010138120 bmdma 0x
irq 16
18.
Dec 16 22:44:29 localhost kernel: ata5: SATA link up 3.0 Gbps
(SStatus 123 SControl 300)
19.
Dec 16 22:44:29 localhost kernel: ata5.00: ATA-7: SAMSUNG SP2504C,
VT100-33, max UDMA7
20.
Dec 16 22:44:29 localhost kernel: ata5.00: 488397168 sectors,
multi 0: LBA48 NCQ (depth 0/32)
21.
Dec 16 22:44:29 localhost kernel: ata5.00: configured for UDMA/133
22.
Dec 16 22:44:29 localhost kernel: ata6: SATA link up 3.0 Gbps
(SStatus 123 SControl 300)
23.
Dec 16 22:44:29 localhost kernel: ata6.00: ATA-7: SAMSUNG SP2504C,
VT100-33, max UDMA7
24.
Dec 16 22:44:29 localhost kernel: ata6.00: 488397168 sectors,
multi 0: LBA48 NCQ (depth 0/32)
25.
Dec 16 22:44:29 localhost kernel: ata6.00: configured for UDMA/133
26.
Dec 16 22:44:29 localhost kernel: ata7: SATA link up 3.0 Gbps
(SStatus 123 SControl 300)
27.
Dec 16 22:44:29 localhost kernel: ata7.00: ATA-7: SAMSUNG SP2504C,
VT100-33, max UDMA7
28.
Dec 16 22:44:29 localhost kernel: ata7.00: 488397168 sectors,
multi 0: LBA48 NCQ (depth 0/32)
29.
Dec 16 22:44:29 localhost kernel: ata7.00: configured for UDMA/133
30.
Dec 16 22:44:29 localhost kernel: ata8: SATA link up 3.0 Gbps
(SStatus 123 SControl 300)
31.
Dec 16 22:44:29 localhost kernel: ata8.00: ATA-7: SAMSUNG SP2504C,
VT100-33, max UDMA7
32.
Dec 16 22:44:29 localhost kernel: ata8.00: 488397168 sectors,
multi 0: LBA48 NCQ (depth 0/32)
33.
Dec 16 22:44:29 localhost kernel: ata8.00: configured for UDMA/133
34.
Dec 16 22:44:29 localhost kernel: ata9: SATA link up 3.0 Gbps
(SStatus 123 SControl 300)
35.
Dec 16 22:44:29 localhost kernel: ata9.00: ATA-7: SAMSUNG SP2504C,
VT100-33, max UDMA7
36.
Dec 16 22:44:29 localhost kernel: ata9.00: 488397168 sectors,
multi 0: LBA48 NCQ (depth 0/32)
37.
Dec 16 22:44:29 localhost kernel: ata9.00: configured for UDMA/133
38.
Dec 16 22:44:29 localhost kernel: ata10: SATA link down (SStatus 0
SControl 300)
39.
Dec 16 22:44:29 localhost kernel: ata11: SATA link up 3.0 Gbps
(SStatus 123 SControl 300)
40.
Dec 16 22:44:29 localhost kernel: ata11.00: ATA-7: SAMSUNG
SP2504C, VT100-33, max UDMA7
41.
Dec 16 22:44:29 localhost kernel: ata11.00: 488397168 sectors,
multi 0: LBA48 NCQ (depth 0/32)
42.
Dec 16 22:44:29 localhost kernel: ata11.00: configured for UDMA/133
43.
Dec 16 22:44:29 localhost kernel: ata12: SATA link down (SStatus 0
SControl 300)
44.
Dec 16 22:44:29 localhost kernel: scsi 4:0:0:0: Direct-Access
ATA  SAMSUNG SP2504C  VT10 PQ: 0 ANSI: 5

45.
Dec 16 22:44:29 localhost kernel:

Re: CMD646 cdrom: drive appears confused drive not ready for command


(added linux-ide)

On Sun, 16 Dec 2007 20:36:04 +0200 (EET) Meelis Roos [EMAIL PROTECTED] wrote:

 I just noticed that all my recent test kernels on Sun Ultra 5 spam dmesg 
 with hdc: drive not ready for command messages.  Oldest logs that I 
 have are from 2.6.24-rc4-g94545bad and they are already bad.

So when did thi start?  Is 2.6.23 OK?

 The 
 spamming does not happen right away but some time later, and 
 hald-addon-storage is the userspace daemon that polls the cdrom 
 regularly. Full dmesg until the spamming begins - notice there are first 
 some drive appears confused messages right before it happens.
 
 Dec 15 14:11:00 mandariin kernel: PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 
 2001/07/25 20:36'
 Dec 15 14:11:00 mandariin kernel: PROMLIB: Root node compatible: 
 Dec 15 14:11:00 mandariin kernel: Linux version 2.6.24-rc5-gda8cadb3 ([EMAIL 
 PROTECTED]) (gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)) #38 
 Sat Dec 15 13:00:43 EET 2007
 Dec 15 14:11:00 mandariin kernel: ARCH: SUN4U
 Dec 15 14:11:00 mandariin kernel: Ethernet address: 08:00:20:f8:c7:72
 Dec 15 14:11:00 mandariin kernel: [0002-f880] 
 page_structs=262144 node=0 entry=0/0
 Dec 15 14:11:00 mandariin kernel: [0002-f8c0] 
 page_structs=262144 node=0 entry=1/0
 Dec 15 14:11:00 mandariin kernel: [0002-f8000100] 
 page_structs=262144 node=0 entry=2/0
 Dec 15 14:11:00 mandariin kernel: [0002-f8000140] 
 page_structs=262144 node=0 entry=3/0
 Dec 15 14:11:00 mandariin kernel: OF stdout device is: /[EMAIL 
 PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],40:a
 Dec 15 14:11:00 mandariin kernel: PROM: Built device tree with 42042 bytes of 
 memory.
 Dec 15 14:11:00 mandariin kernel: On node 0 totalpages: 64952
 Dec 15 14:11:00 mandariin kernel:   Normal zone: 447 pages used for memmap
 Dec 15 14:11:00 mandariin kernel:   Normal zone: 0 pages reserved
 Dec 15 14:11:00 mandariin kernel:   Normal zone: 64505 pages, LIFO batch:15
 Dec 15 14:11:00 mandariin kernel:   Movable zone: 0 pages used for memmap
 Dec 15 14:11:00 mandariin kernel: Built 1 zonelists in Zone order, mobility 
 grouping on.  Total pages: 64505
 Dec 15 14:11:00 mandariin kernel: Kernel command line: root=/dev/hda1 ro
 Dec 15 14:11:00 mandariin kernel: PID hash table entries: 2048 (order: 11, 
 16384 bytes)
 Dec 15 14:11:00 mandariin kernel: clocksource: mult[2c71c] shift[16]
 Dec 15 14:11:00 mandariin kernel: clockevent: mult[5c28f5c2] shift[32]
 Dec 15 14:11:00 mandariin kernel: Console: colour dummy device 80x25
 Dec 15 14:11:00 mandariin kernel: console [tty0] enabled
 Dec 15 14:11:00 mandariin kernel: Dentry cache hash table entries: 65536 
 (order: 6, 524288 bytes)
 Dec 15 14:11:00 mandariin kernel: Inode-cache hash table entries: 32768 
 (order: 5, 262144 bytes)
 Dec 15 14:11:00 mandariin kernel: Memory: 501368k available (2696k kernel 
 code, 904k data, 128k init) [f800,1ff42000]
 Dec 15 14:11:00 mandariin kernel: SLUB: Genslabs=12, HWalign=32, Order=0-2, 
 MinObjects=8, CPUs=1, Nodes=1
 Dec 15 14:11:00 mandariin kernel: Calibrating delay using timer specific 
 routine.. 721.25 BogoMIPS (lpj=3606278)
 Dec 15 14:11:00 mandariin kernel: Mount-cache hash table entries: 512
 Dec 15 14:11:00 mandariin kernel: Initializing cgroup subsys ns
 Dec 15 14:11:00 mandariin kernel: net_namespace: 120 bytes
 Dec 15 14:11:00 mandariin kernel: NET: Registered protocol family 16
 Dec 15 14:11:00 mandariin kernel: PCI: Probing for controllers.
 Dec 15 14:11:00 mandariin kernel: /[EMAIL PROTECTED],0: SABRE PCI Bus Module
 Dec 15 14:11:00 mandariin kernel: /[EMAIL PROTECTED],0: PCI IO[1fe0200] 
 MEM[1ff]
 Dec 15 14:11:00 mandariin kernel: PCI: Scanning PBM /[EMAIL PROTECTED],0
 Dec 15 14:11:00 mandariin kernel: ebus0: [auxio] [power] [SUNW,pll] [se] [su] 
 [su] [ecpp] [fdthree] [eeprom] [flashprom] [SUNW,CS4231]
 Dec 15 14:11:00 mandariin kernel: power: Control reg at 1fff1724000
 Dec 15 14:11:00 mandariin kernel: SCSI subsystem initialized
 Dec 15 14:11:00 mandariin kernel: libata version 3.00 loaded.
 Dec 15 14:11:00 mandariin kernel: AUXIO: Found device at /[EMAIL 
 PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],726000
 Dec 15 14:11:00 mandariin kernel: /[EMAIL PROTECTED],0/[EMAIL 
 PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0: Clock regs at 
 01fff100
 Dec 15 14:11:00 mandariin kernel: NET: Registered protocol family 2
 Dec 15 14:11:00 mandariin kernel: Time: tick clocksource has been installed.
 Dec 15 14:11:00 mandariin kernel: Switched to high resolution mode on CPU 0
 Dec 15 14:11:00 mandariin kernel: IP route cache hash table entries: 4096 
 (order: 2, 32768 bytes)
 Dec 15 14:11:00 mandariin kernel: TCP established hash table entries: 16384 
 (order: 5, 262144 bytes)
 Dec 15 14:11:00 mandariin kernel: TCP bind hash table entries: 16384 (order: 
 4, 131072 bytes)
 Dec 15 14:11:00 mandariin kernel:

Re: [PATCH 0/1] IPN: Inter Process Networking

2007-12-17 Thread david


On Mon, 17 Dec 2007, Ludovico Gardenghi wrote:


On Mon, Dec 17, 2007 at 03:31:48AM -0800, [EMAIL PROTECTED] wrote:


wouldn't it be better to just add the ability for multiple writers to send
to the same pipe, and then have all of them splice into the output of that
pipe? this would give the same data-agnostic communication that you are
looking for, and with the minor detail that software would have to filter
out messages that they send, would appear to meet all the goals you are
looking at, useing existing kernel features that are designed to be very
high performance.


Being able to define both filtering policies (think of a virtual
ethernet layer 2 switch, for instance. We have situations where dozens
or hundreds of virtual cables are connected to the same switch, it would
be much, much slower if you had to awake all the user processes for each
single non-broadcast ethernet frame, and send them useless data) and
delivery guarantees (lossless vs best-effort delivery) are not minor
details in our opinion.

We might have added a level2 virtual ethernet switch at kernel
level, but it seemed to specific. With a minor effort we have split the
dumb bus (IPN) and the ability to process specific structured data
with specific policies (sub-modules as kvde_switch).


it seems like you are mixing your use cases and arguing reasons for one 
when answering questions about another.


if you are talking network connections between virtual systems, then the 
exiting tap interfaces would seem to do everything you are looking for. 
you can add them to bridges, route between them, filter traffic between 
them (at whatever layer you want with netfilter), use multicast, etc as 
you would any real interface.


if, however, you are talking about non-network communications (your 
example of sending raw video frames across the interface), and want 
multiple processes to receive them, this sounds like exactly the thing 
that splice was designed to do, distribute data to multiple recipiants 
simultaniously and efficiantly.


I think you need to seperate out these two use cases (and any others you 
are advocating this for) and argue each one on it's own.



We surely may adapt existing features (AF_UNIX, or pipes) but they offer
a quite established interface and semantics and we think it should be
better to add a new family. This would prevent from breaking what
already exists and leaving more freedom in defining the new family
according to needs.


for a new family to be valuble, you need to show what it does that isn't 
available in existing families.



As for ptrace vs utrace: ptrace has been designed for debugging; trying
to bend it to be fit for virtualization is likely to end up in an
intricated interface and implementation. utrace has been designed in a
much more general way. You can implement ptrace over utrace, but you can
use utrace also for virtualization in a cleaner, simpler and more
efficient way. Why not?


I'm not familiar enough with ptrace vs utrace to know this argument. but I 
haven't heard any of the virtualization people complaining about the 
existing interfaces. They seem to have been happily useing them for a 
number of years.


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

Re: CMD646 cdrom: drive appears confused drive not ready for command

On Mon, 17 Dec 2007 02:59:03 -0800 Andrew Morton [EMAIL PROTECTED] wrote:

 
 (added linux-ide)

(Ths time for real)

 On Sun, 16 Dec 2007 20:36:04 +0200 (EET) Meelis Roos [EMAIL PROTECTED] 
 wrote:
 
  I just noticed that all my recent test kernels on Sun Ultra 5 spam dmesg 
  with hdc: drive not ready for command messages.  Oldest logs that I 
  have are from 2.6.24-rc4-g94545bad and they are already bad.
 
 So when did thi start?  Is 2.6.23 OK?
 
  The 
  spamming does not happen right away but some time later, and 
  hald-addon-storage is the userspace daemon that polls the cdrom 
  regularly. Full dmesg until the spamming begins - notice there are first 
  some drive appears confused messages right before it happens.
  
  Dec 15 14:11:00 mandariin kernel: PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 
  2001/07/25 20:36'
  Dec 15 14:11:00 mandariin kernel: PROMLIB: Root node compatible: 
  Dec 15 14:11:00 mandariin kernel: Linux version 2.6.24-rc5-gda8cadb3 
  ([EMAIL PROTECTED]) (gcc version 4.2.3 20071123 (prerelease) (Debian 
  4.2.2-4)) #38 Sat Dec 15 13:00:43 EET 2007
  Dec 15 14:11:00 mandariin kernel: ARCH: SUN4U
  Dec 15 14:11:00 mandariin kernel: Ethernet address: 08:00:20:f8:c7:72
  Dec 15 14:11:00 mandariin kernel: [0002-f880] 
  page_structs=262144 node=0 entry=0/0
  Dec 15 14:11:00 mandariin kernel: [0002-f8c0] 
  page_structs=262144 node=0 entry=1/0
  Dec 15 14:11:00 mandariin kernel: [0002-f8000100] 
  page_structs=262144 node=0 entry=2/0
  Dec 15 14:11:00 mandariin kernel: [0002-f8000140] 
  page_structs=262144 node=0 entry=3/0
  Dec 15 14:11:00 mandariin kernel: OF stdout device is: /[EMAIL 
  PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL 
  PROTECTED],40:a
  Dec 15 14:11:00 mandariin kernel: PROM: Built device tree with 42042 bytes 
  of memory.
  Dec 15 14:11:00 mandariin kernel: On node 0 totalpages: 64952
  Dec 15 14:11:00 mandariin kernel:   Normal zone: 447 pages used for memmap
  Dec 15 14:11:00 mandariin kernel:   Normal zone: 0 pages reserved
  Dec 15 14:11:00 mandariin kernel:   Normal zone: 64505 pages, LIFO batch:15
  Dec 15 14:11:00 mandariin kernel:   Movable zone: 0 pages used for memmap
  Dec 15 14:11:00 mandariin kernel: Built 1 zonelists in Zone order, mobility 
  grouping on.  Total pages: 64505
  Dec 15 14:11:00 mandariin kernel: Kernel command line: root=/dev/hda1 ro
  Dec 15 14:11:00 mandariin kernel: PID hash table entries: 2048 (order: 11, 
  16384 bytes)
  Dec 15 14:11:00 mandariin kernel: clocksource: mult[2c71c] shift[16]
  Dec 15 14:11:00 mandariin kernel: clockevent: mult[5c28f5c2] shift[32]
  Dec 15 14:11:00 mandariin kernel: Console: colour dummy device 80x25
  Dec 15 14:11:00 mandariin kernel: console [tty0] enabled
  Dec 15 14:11:00 mandariin kernel: Dentry cache hash table entries: 65536 
  (order: 6, 524288 bytes)
  Dec 15 14:11:00 mandariin kernel: Inode-cache hash table entries: 32768 
  (order: 5, 262144 bytes)
  Dec 15 14:11:00 mandariin kernel: Memory: 501368k available (2696k kernel 
  code, 904k data, 128k init) [f800,1ff42000]
  Dec 15 14:11:00 mandariin kernel: SLUB: Genslabs=12, HWalign=32, Order=0-2, 
  MinObjects=8, CPUs=1, Nodes=1
  Dec 15 14:11:00 mandariin kernel: Calibrating delay using timer specific 
  routine.. 721.25 BogoMIPS (lpj=3606278)
  Dec 15 14:11:00 mandariin kernel: Mount-cache hash table entries: 512
  Dec 15 14:11:00 mandariin kernel: Initializing cgroup subsys ns
  Dec 15 14:11:00 mandariin kernel: net_namespace: 120 bytes
  Dec 15 14:11:00 mandariin kernel: NET: Registered protocol family 16
  Dec 15 14:11:00 mandariin kernel: PCI: Probing for controllers.
  Dec 15 14:11:00 mandariin kernel: /[EMAIL PROTECTED],0: SABRE PCI Bus Module
  Dec 15 14:11:00 mandariin kernel: /[EMAIL PROTECTED],0: PCI IO[1fe0200] 
  MEM[1ff]
  Dec 15 14:11:00 mandariin kernel: PCI: Scanning PBM /[EMAIL PROTECTED],0
  Dec 15 14:11:00 mandariin kernel: ebus0: [auxio] [power] [SUNW,pll] [se] 
  [su] [su] [ecpp] [fdthree] [eeprom] [flashprom] [SUNW,CS4231]
  Dec 15 14:11:00 mandariin kernel: power: Control reg at 1fff1724000
  Dec 15 14:11:00 mandariin kernel: SCSI subsystem initialized
  Dec 15 14:11:00 mandariin kernel: libata version 3.00 loaded.
  Dec 15 14:11:00 mandariin kernel: AUXIO: Found device at /[EMAIL 
  PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],726000
  Dec 15 14:11:00 mandariin kernel: /[EMAIL PROTECTED],0/[EMAIL 
  PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0: Clock regs at 
  01fff100
  Dec 15 14:11:00 mandariin kernel: NET: Registered protocol family 2
  Dec 15 14:11:00 mandariin kernel: Time: tick clocksource has been installed.
  Dec 15 14:11:00 mandariin kernel: Switched to high resolution mode on CPU 0
  Dec 15 14:11:00 mandariin kernel: IP route cache hash table entries: 4096 
  (order: 2, 32768 bytes)
  Dec 15 14:11:00 mandariin kernel: TCP established

Re: [PATCH] sound/core.h: include sound/driver.h

2007-12-17 Thread Takashi Iwai

At Sun, 16 Dec 2007 02:58:31 +0100,
Marcin Slusarz wrote:
 
 On Fri, Dec 14, 2007 at 12:02:46PM +0100, Takashi Iwai wrote:
  At Sat, 8 Dec 2007 21:50:45 +0100,
  Marcin Ślusarz wrote:
  
   sound/core.h: include sound/driver.h
  
   include sound/driver.h in sound/core.h because core.h
   uses SNDRV_CARDS (which is defined in sound/driver.h)
  
   Signed-off-by: Marcin Ślusarz [EMAIL PROTECTED]
 
  Right now I have another (bigger) change for this include path, so
  this patch won't be needed any more.
 
  I applied the patches to sound/* except for this one and
  sound/memory.c.   Thanks!
 
 Is there anything wrong with patch for rawmidi [1]?

Ah, sorry, forgot to mention it.

I'm still considering whether it's the best way.  The changes look
exaggerated just for fixing sparse warnings.


Takashi

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

Re: [argyllcms] Re: [PATCH] usb/hid: Blacklist the Gretag-Macbeth Huey display colorimeter

2007-12-17 Thread Nicolas Mailhot

[Replying twice because I replied to the wrong message at first]

Le dimanche 16 décembre 2007 à 17:59 +0100, Jiri Kosina a écrit :

 What exactly is the problem here? I didn't seem to catch the beginning of 
 the thread (or it happened off the list I am subscribed to).

For more info on usb colorimeter problems you can check
http://www.freelists.org/archives/argyllcms/12-2007/

It seems Graeme Gill, the Argyll CMS author has hit several linux usb
problems over the years but has not coordinated well with the Linux usb
maintainers. We're finding all the ugly bits now that we're trying to
meger Argyll CMS in various distributions (Fedora, Mandriva, Ubuntu,
etc)

It's a bit difficult to follow this thread because the argyllcms list is
killing CCs and not everyone is putting them back in.

Regards,

-- 
Nicolas Mailhot


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: CMD646 cdrom: drive appears confused drive not ready for command

2007-12-17 Thread Meelis Roos

  So when did thi start?  Is 2.6.23 OK?

I have 2.6.23 running now and will see if something happens.

  Are there any other consequences apart from log spam?

Any CD communication seems to be impossible after this starts. Will 
retest when it happens again.

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

Re: RFC: remove __read_mostly

On Mon, 17 Dec 2007 11:53:36 +0100 Eric Dumazet [EMAIL PROTECTED] wrote:

 n Mon, 17 Dec 2007 02:33:39 -0800
 Andrew Morton [EMAIL PROTECTED] wrote:
 
  On Fri, 14 Dec 2007 01:33:45 +0100 Andi Kleen [EMAIL PROTECTED] wrote:
  
   Kyle McMartin [EMAIL PROTECTED] writes:
   
I'd bet, in the __read_mostly case at least, that there's no
improvement in almost all cases.
   
   I bet you're wrong. Cache line behaviour is critical, much more
   than pipeline behaviour (which unlikely affects). That is because
   if you eat a cache miss it gets really expensive, which e.g.
   a mispredicted jump is relatively cheap in comparison. We're talking
   one or more orders of magnitude.
  
  So...  once we've moved all read-mostly variables into __read_mostly, what
  is left behind in bss?
  
  All the write-often variables.  All optimally packed together to nicely
  maximise cacheline sharing.
 
 This is why it's important to group related variables together, so that they 
 share
 same cacheline.

Not feasible.  The linker is (I believe) free to place them anywhere it
likes unless we go and aggregate them in a struct.

Take (just for one example) inode_lock.  How do we prevent that from
sharing a cacheline with (to pick another example) rtnl_mutex?

The insidious thing about this is that is is highly dependent upon
compiler/linker version and upon kernel config.  So performance differences
will appears and disappear with us having very little understanding why.


I guess we could hunt down the write-very-often variables and put them in
private cachelines.  But there will be a *lot* of them when one considers
all possible workloads and all possible drivers.


Now, if we had named it __read_often rather than __read_mostly then we might
end up with a better result: all those read-mostly, read-rarely variables (and
there are a lot of those) could be very usefully deployed by packing them
in between the write-often variables.

It's crying out for a performance-guided solution.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc5: tape drive not responding

On Mon, 17 Dec 2007 11:25:51 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote:

 On Sun, 16 Dec 2007 20:05:51 -0500
 John Stoffel [EMAIL PROTECTED] wrote:
 
  [  215.007701] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  215.008145] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  215.008678] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  215.009122] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  215.009598] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  215.010042] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  215.010516] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  215.010959] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  215.011403] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  215.011850] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  .
  .
  .
  [  232.954629] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  233.035902] scsi 3:0:3:0: DEVICE RESET operation started
  [  233.099514] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  .
  .
  .
  
  These repeat for about 15 seconds or so.  They're really annoying and
  I'd love to see some sort of rate limiting put in here.  The messages
  and end with:
  .
  .
  .
  [  238.084175] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  238.165887] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  238.247157] scsi 3:0:3:0: DEVICE RESET operation timed-out.
  [  238.313892] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  238.395192] scsi 3:0:3:0: BUS RESET operation started
  [  238.455690] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
  [  238.539216] sym1: SCSI BUS reset detected.
  [  238.592552] sym1: SCSI BUS has been reset.
  [  238.641576] scsi 3:0:3:0: BUS RESET operation complete.
  [  248.700373]  target3:0:3: wide asynchronous
  [  248.752026]  target3:0:3: Wide Transfers Fail
  [  248.805220]  target3:0:3: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
  [  248.886729]  target3:0:3: Domain Validation skipping write tests
  [  248.958666]  target3:0:3: Ending Domain Validation
  [  252.264086] scsi 3:0:0:0: Attached scsi generic sg2 type 8
  [  252.331257] st 3:0:2:0: Attached scsi tape st0
  [  252.384549] st 3:0:2:0: st0: try direct i/o: yes (alignment 512 B)
  [  252.458875] st 3:0:2:0: Attached scsi generic sg3 type 1
  [  252.523963] st 3:0:3:0: Attached scsi tape st1
  [  252.577184] st 3:0:3:0: st1: try direct i/o: yes (alignment 512 B)
  [  252.651484] st 3:0:3:0: Attached scsi generic sg4 type 1
  
  
  I've also got an ATL P1000 SCSI tape library hooked up to this same
  controller and port, and I can manipulate it properly using the 'mtx'
  program pointed to the /dev/changer alias, which points to the correct
  /dev/sg# device.
  
  Here's my /proc/scsi/scsi output, as you can see, I've got a bunch of
  devices on this system:
  
  # cat /proc/scsi/scsi 
  Attached devices:
  Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: COMPAQ   Model: HC01841729   Rev: 3208
Type:   Direct-AccessANSI  SCSI revision: 02
  Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: COMPAQ   Model: BD018222CA   Rev: B016
Type:   Direct-AccessANSI  SCSI revision: 02
  Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: ATL  Model: P10006220051 Rev: 1.20
Type:   Medium Changer   ANSI  SCSI revision: 02
  Host: scsi3 Channel: 00 Id: 02 Lun: 00
Vendor: QUANTUM  Model: DLT7000  Rev: 2565
Type:   Sequential-AccessANSI  SCSI revision: 02
  Host: scsi3 Channel: 00 Id: 03 Lun: 00
Vendor: QUANTUM  Model: DLT7000  Rev: 2565
Type:   Sequential-AccessANSI  SCSI revision: 02
  Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: SAMSUNG  Model: CDRW/DVD SM-352B Rev: T806
Type:   CD-ROM   ANSI  SCSI revision: 05
  Host: scsi6 Channel: 00 Id: 00 Lun: 00
Vendor: ATA  Model: ST3320620AS  Rev: 3.AA
Type:   Direct-AccessANSI  SCSI revision: 05
  Host: scsi7 Channel: 00 Id: 00 Lun: 00
Vendor: ATA  Model: WDC WD3200AAKS-0 Rev: 12.0
Type:   Direct-AccessANSI  SCSI revision: 05
  Host: scsi10 Channel: 00 Id: 00 Lun: 00
Vendor: ATA  Model: WDC WD1200JB-00C Rev: 17.0
Type:   Direct-AccessANSI  SCSI revision: 05
  Host: scsi11 Channel: 00 Id: 00 Lun: 00
Vendor: ATA  Model: WDC WD1200JB-00E Rev: 15.0
Type:   Direct-AccessANSI  SCSI revision: 05
  Host: scsi12 Channel: 00 Id: 00 Lun: 00
Vendor: Generic  Model: STORAGE DEVICE   Rev: 0001
Type:   Direct-AccessANSI  SCSI revision: 00
  Host: scsi12 Channel: 00 Id: 00 Lun: 01
Vendor: Generic  Model: STORAGE DEVICE   Rev:

Re: How to Switch DMA off for only one Harddisk at Kernelboot

2007-12-17 Thread Oliver Joa


Hi,

Alan Cox wrote:

[...]


For the current kernel and libata you can use libata.dma=3, and it will
select DMA for disk (1) + CD (2) but not CF cards. With the older IDE it
should be sufficient to use hda=nodma


Thanks a lot, but it does not work:

If I use libata.dma=3 I get the following:
[0.00] Unknown boot option `libata.dma=3': ignoring

And if I use hda=nodma:
[0.00] ide_setup: hda=nodma -- BAD OPTION

I use kernel 2.6.21.5.

Any Idea?

Thanks

Olli
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 recursive locking detected with XFS

2007-12-17 Thread David Chinner

On Thu, Dec 13, 2007 at 06:29:16PM +0300, Vladislav Bolkhovitin wrote:
 I've just got it while running dbench 200 over a XFS mounted 
 partition. Kernel is 2.6.23. See the attachment.
..
 Dec 13 16:30:45 tst kernel: [  917.365836] 
 =
 Dec 13 16:30:45 tst kernel: [  917.372856] [ INFO: possible recursive locking 
 detected ]
 Dec 13 16:30:45 tst kernel: [  917.378269] 2.6.23-dbg #17
 Dec 13 16:30:45 tst kernel: [  917.381435] 
 -
 Dec 13 16:30:45 tst kernel: [  917.386838] dbench/3538 is trying to acquire 
 lock:
 Dec 13 16:30:45 tst kernel: [  917.391687]  
 ((ip-i_iolock)-mr_lock){}, at: [f89ad79c] xfs_ilock+0x90/0x9c [xfs]
 Dec 13 16:30:45 tst kernel: [  917.400262] 
 Dec 13 16:30:45 tst kernel: [  917.400264] but task is already holding lock:
 Dec 13 16:30:45 tst kernel: [  917.406116]  
 ((ip-i_iolock)-mr_lock){}, at: [f89ad79c] xfs_ilock+0x90/0x9c [xfs]
 Dec 13 16:30:45 tst kernel: [  917.414503] 
 Dec 13 16:30:45 tst kernel: [  917.414505] other info that might help us 
 debug this:
 Dec 13 16:30:45 tst kernel: [  917.421242] 3 locks held by dbench/3538:
 Dec 13 16:30:45 tst kernel: [  917.425178]  #0:  (inode-i_mutex){--..}, at: 
 [783626a6] mutex_lock+0x1c/0x1f
 Dec 13 16:30:45 tst kernel: [  917.432805]  #1:  
 ((ip-i_iolock)-mr_lock){}, at: [f89ad79c] xfs_ilock+0x90/0x9c [xfs]
 Dec 13 16:30:45 tst kernel: [  917.441696]  #2:  
 (type-s_umount_key#17){}, at: [78191411] writeback_inodes+0x88/0xd5
 Dec 13 16:30:45 tst kernel: [  917.450578] 
 Dec 13 16:30:45 tst kernel: [  917.450582] stack backtrace:
 Dec 13 16:30:45 tst kernel: [  917.455011]  [78103d59] 
 show_trace_log_lvl+0x1a/0x30
 Dec 13 16:30:45 tst kernel: [  917.460279]  [7810488d] show_trace+0x12/0x14
 Dec 13 16:30:45 tst kernel: [  917.464759]  [781048a5] dump_stack+0x16/0x18
 Dec 13 16:30:45 tst kernel: [  917.469262]  [7813f883] 
 __lock_acquire+0xdd1/0x106e
 Dec 13 16:30:45 tst kernel: [  917.474360]  [7813fb89] 
 lock_acquire+0x69/0x82
 Dec 13 16:30:45 tst kernel: [  917.479000]  [78136184] 
 down_write_nested+0x40/0x88
 Dec 13 16:30:45 tst kernel: [  917.484195]  [f89ad79c] xfs_ilock+0x90/0x9c 
 [xfs]
 Dec 13 16:30:45 tst kernel: [  917.489180]  [f89d13b7] 
 xfs_inactive+0x329/0x4ed [xfs]
 Dec 13 16:30:45 tst kernel: [  917.494565]  [f89dc052] 
 xfs_fs_clear_inode+0x7a/0xbe [xfs]
 Dec 13 16:30:45 tst kernel: [  917.500415]  [78188a78] 
 clear_inode+0xb2/0x14d
 Dec 13 16:30:45 tst kernel: [  917.505078]  [78188c0b] 
 generic_delete_inode+0xf8/0x105
 Dec 13 16:30:45 tst kernel: [  917.510513]  [78188d27] 
 generic_drop_inode+0x10f/0x141
 Dec 13 16:30:45 tst kernel: [  917.515854]  [78188226] iput+0x5f/0x66
 Dec 13 16:30:45 tst kernel: [  917.519836]  [781911ae] 
 sync_sb_inodes+0x1f6/0x25c
 Dec 13 16:30:45 tst kernel: [  917.525032]  [7819142f] 
 writeback_inodes+0xa6/0xd5
 Dec 13 16:30:45 tst kernel: [  917.530070]  [7815c9f3] 
 balance_dirty_pages_ratelimited_nr+0xdd/0x204
 Dec 13 16:30:45 tst kernel: [  917.536716]  [781580e4] 
 generic_file_buffered_write+0x2e2/0x69c
 Dec 13 16:30:45 tst kernel: [  917.542855]  [f89db3fe] 
 xfs_write+0x619/0xaab [xfs]
 Dec 13 16:30:45 tst kernel: [  917.547990]  [f89d776e] 
 xfs_file_aio_write+0x70/0x7c [xfs]
 Dec 13 16:30:45 tst kernel: [  917.553770]  [78175d65] 
 do_sync_write+0xd0/0x106
 Dec 13 16:30:45 tst kernel: [  917.558620]  [78176552] vfs_write+0x8b/0x149
 Dec 13 16:30:45 tst kernel: [  917.563113]  [78176bc4] sys_write+0x3d/0x64
 Dec 13 16:30:45 tst kernel: [  917.567526]  [78102ca2] 
 sysenter_past_esp+0x5f/0x99
 Dec 13 16:30:45 tst kernel: [  917.572635]  ===

Oh, this is the classic recurse into the filesystem to do something
that requires locks while holding a lock on a different inode false positive.

Basically, we are holding the iolock on inode A when we call
generic_file_buffered_write() and that does something that takes the
iolock on inode B which triggers the report because we don't normally
nest iolocks. We also see this regularly with memory reclaim being
triggered from within the filesystem.

AFAICT, there is no way we can annotate these cases because they are
completely disconnected - there is no relationship or dependency between
the two inodes and so false positives due to recursion like this seems
to me to be impossible to annotate away cleanly.

Cheers,

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

Re: INITIO scsi driver fails to work properly

On Mon, 17 Dec 2007 11:39:47 +0200 Filippos Papadopoulos [EMAIL PROTECTED] 
wrote:

 Hi,
 I have got an INITIO 9100 UW SCSI Controller with an IBM
 IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
 Currently i have SUSE 10.1 (Kernel 2.6.16).
 
 I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
 OpenSUSE 11.0 Alpha 0  (kernel 2.6.24-rc4) but although the initio
 driver
 gets loaded during the installation process, yast reports that no hard
 disk is found. I believe that this isnt a bug in suse's yast but a
 problem
 in the initio scsi driver because i also tried to install Fedora 8
 (kernel 2.6.23) with the same problem.
 I have seen the relevant thread Conflict when loading initio driver
 and i suppose that the initio driver isnt fixed yet.
 I can help testing the new patches in the initio driver if someone is
 interested.

initio doesn't seem to have a maintainer...

Are you able to identify any earlier kernel which worked OK?

Maybe it's a new device?  If you can get the `lspci -vvxx' output
for that device we can take a look.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] power: RFC: introduce a new power API

2007-12-17 Thread Anton Vorontsov

On Mon, Dec 17, 2007 at 02:41:39AM -0500, Andres Salomon wrote:
[...]
   On Sun, 2007-12-16 at 21:24 -0500, Andres Salomon wrote:
This API has the power_supply drivers device their own device_attribute
list; I find this to be a lot more flexible and cleaner.  
  
  I don't see how this is more flexible and cleaner. See below.
  
For example,
rather than having a function with a huge switch statement (as 
olpc_battery
currently has), we have separate callback functions.
  
  Is this an improvement? Look into ds2760_battery.c. I scared to
  imagine what it will look like after conversion.
 
 Why?  It would not look bad after conversion.  Basically:
 
 static ssize_t ds2760_battery_get_status(struct device *dev,
 struct device_attribute *attr, char *buf)
 {
   struct ds2760_device_info *di = to_ds2760_device_info(psy);
   return power_supply_status_str(di-charge_status, buf);
 }
 static ssize_t ds2760_battery_get_voltage_now(struct device *dev,
 struct device_attribute *attr, char *buf)
 {
   struct ds2760_device_info *di = to_ds2760_device_info(psy);
   ds2760_battery_read_status(di);
   return sprintf(buf, %d\n, di-voltage_uV);
 }
 
 an so on.
 
 If I wanted to get really clever, I could do:
 
 #define DS2760_CALLBACK(name, fmt, var)   \
 static ssize_t ds2760_battery_get_##name(struct device *dev,  \
   struct device_attribute *attr, char *buf) \
 { \
   struct ds2760_device_info *di = to_ds2760_device_info(psy); \
 ds2760_battery_read_status(di);   \
   return sprintf(buf, fmt, var);\
 }
 
 DS2760_CALLBACK(voltage_now, %d\n, di-voltage_uV)
 DS2760_CALLBACK(current_now, %d\n, di-current_uA)
 
 etc.. but, I'm not trying to compress lines of code, I'm trying
 to ensure things are readable.

Hehe, look: http://lkml.org/lkml/2007/4/11/397

These macros are indeed what I've tried to avoid, dozen open-coded
similar functions not a good option either. I also tried to avoid
function per property stuff...

[lots of sense snipped]

I see your point now. Basically, now I'm encourage to think just one
more time: is there third (better) option in addition to current and
this? I still hope there is some not obvious, but elegant solution.
If there isn't, I'm ready to surrender and will help with everything
I can.


Thanks!

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 V2] ipwireless_cs driver for 4G PC Card

On Mon, 17 Dec 2007 11:57:46 +0100 (CET) Jiri Kosina [EMAIL PROTECTED] wrote:

 [ CC list trimmed ] 

often a bad idea...

 On Wed, 12 Dec 2007, David Sterba wrote:
 
  Changelog:
  * files moved to ipwireless/, ipwireless_cs_ stripped from filenames
  * _cs stripped from driver name
  * kmalloc checks
  * sync irq during shutdown
  * removed /proc code, converted to module params
  
  When merged, please drop ipwireless_cs.git tree from -mm and
  include the patch instead.
  
  Regards,
  David Sterba
  
  Rewieved-by: Jiri Slaby [EMAIL PROTECTED]
  Signed-off-by: Ben Martel [EMAIL PROTECTED]
  Signed-off-by: Stephen Blackheath [EMAIL PROTECTED]
  Signed-off-by: David Sterba [EMAIL PROTECTED]
  Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
  ---
   MAINTAINERS |8 
   drivers/char/pcmcia/Kconfig |9 
   drivers/char/pcmcia/Makefile|2 
   drivers/char/pcmcia/ipwireless/Makefile |   10 
   drivers/char/pcmcia/ipwireless/hardware.c   | 1784 
  
   drivers/char/pcmcia/ipwireless/hardware.h   |   63 
   drivers/char/pcmcia/ipwireless/main.c   |  496 ++
   drivers/char/pcmcia/ipwireless/main.h   |   70 
   drivers/char/pcmcia/ipwireless/network.c|  513 ++
   drivers/char/pcmcia/ipwireless/network.h|   54 
   drivers/char/pcmcia/ipwireless/setup_protocol.h |  108 +
   drivers/char/pcmcia/ipwireless/tty.c|  687 +
   drivers/char/pcmcia/ipwireless/tty.h|   48 
   13 files changed, 3852 insertions(+)
 
 Andrew, what is your position on merging this into your 2.6.25 queue 
 please? David has fixed all the issues that came up during review, so it 
 seems to be that it's time for the driver to be merged during the upcoming 
 merge window.
 
 If you take it, I am perfectly fine with you dropping the 
 ipwireless_cs git tree from -mm lineup.
 

I'd have thought that you'd merge it into git-ipwireless_cs.patch and that
you would then take care of merging it into mainline at an appropriate
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] x86: provide a DMI based port 0x80 I/O delay override.


* Ingo Molnar [EMAIL PROTECTED] wrote:

  So how is this? Also fixes a few problems with the previous version.
 
 thanks Rene! I've added your patch to x86.git. I changed a few things 
 ontop of it, see the additional changelog and delta patch below.

here's an updated rollup patch, against 2.6.24-rc4. David, could you 
please try this? This should work out of box on your system, without any 
boot option or other tweak needed.

Ingo

-
Subject: x86: provide a DMI based port 0x80 I/O delay override.
From: Rene Herman [EMAIL PROTECTED]

x86: provide a DMI based port 0x80 I/O delay override.

Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the alternate
diagnostic port 0xed (as used by some BIOSes as well) for these.

David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with hwclock use being a direct trigger.

Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist but that approach has
two problems.

First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but...

Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally some drivers may be racy on SMP without the bus
locking outb.

Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.

This also introduces a command-line parameter io_delay to override
the DMI based choice again:

io_delay=0x80|0xed|udelay|none

where 0x80 means using the standard port 0x80 and 0xed means the
alternate port 0xed.

All these methods can also be selected via the kernel .config,
and can be runtime tuned via /proc/sys/kernel/io_delay_type (for
debugging purposes).

The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.

This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.

[ [EMAIL PROTECTED]:
  - add the io_delay=none method
  - make each method selectable from the kernel config
  - eliminate the indirect function calls
  - add the /proc/sys/kernel/io_delay_type sysctl
  - change 'standard' and 'alternate' to 0x80 and 0xed
  - make the io delay config not depend on CONFIG_DEBUG_KERNEL ]

Signed-off-by: Rene Herman [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
---
 Documentation/kernel-parameters.txt |   10 +++
 arch/x86/Kconfig.debug  |   74 
 arch/x86/boot/compressed/misc_32.c  |8 +--
 arch/x86/boot/compressed/misc_64.c  |8 +--
 arch/x86/kernel/Makefile_32 |2 
 arch/x86/kernel/Makefile_64 |2 
 arch/x86/kernel/io_delay.c  |   95 
 arch/x86/kernel/setup_32.c  |2 
 arch/x86/kernel/setup_64.c  |2 
 include/asm-x86/io_32.h |8 +--
 include/asm-x86/io_64.h |   29 ++
 kernel/sysctl.c |9 +++
 12 files changed, 224 insertions(+), 25 deletions(-)

Index: linux-x86.q/Documentation/kernel-parameters.txt
===
--- linux-x86.q.orig/Documentation/kernel-parameters.txt
+++ linux-x86.q/Documentation/kernel-parameters.txt
@@ -785,6 +785,16 @@ and is between 256 and 4096 characters. 
for translation below 32 bit and if not available
then look in the higher range.
 
+   io_delay=   [X86-32,X86-64] I/O delay method
+   0x80
+   Standard port 0x80 based delay
+   0xed
+   Alternate port 0xed based delay (needed on some systems)
+   udelay
+   Simple two microseconds delay
+   none
+   No delay
+
io7=[HW] IO7 for Marvel based alpha systems
See comment before marvel_specify_io7 in
arch/alpha/kernel/core_marvel.c.
Index: linux-x86.q/arch/x86/Kconfig.debug

Re: INITIO scsi driver fails to work properly

2007-12-17 Thread Filippos Papadopoulos

On Dec 17, 2007 1:18 PM, Andrew Morton [EMAIL PROTECTED] wrote:

On Mon, 17 Dec 2007 11:39:47 +0200 Filippos Papadopoulos [EMAIL
PROTECTED] wrote:

Hi,
I have got an INITIO 9100 UW SCSI Controller with an IBM
IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
Currently i have SUSE 10.1 (Kernel 2.6.16).

I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
driver
gets loaded during the installation process, yast reports that no hard
disk is found. I believe that this isnt a bug in suse's yast but a
problem
in the initio scsi driver because i also tried to install Fedora 8
(kernel 2.6.23) with the same problem.
I have seen the relevant thread Conflict when loading initio driver
and i suppose that the initio driver isnt fixed yet.
I can help testing the new patches in the initio driver if someone is
interested.

initio doesn't seem to have a maintainer...

Are you able to identify any earlier kernel which worked OK?

I have this PC configuration since 2002. The initio driver worked
perfectly with 2.4 kernel series.
With the release of 2.6 kernel series the driver had been marked as
BROKEN and fixed at 2.6.9
(see at
http://www.gossamer-threads.com/lists/linux/kernel/482582?search_string=SCSI%20updates%20for%202.6.9;#482582
Christoph Hellwig -don't mark the initio 9100 driver broken)

Maybe it's a new device? If you can get the `lspci -vvxx' output
for that device we can take a look.

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

Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu

2007-12-17 Thread Neil Horman

On Thu, Dec 13, 2007 at 10:32:22AM -0500, Neil Horman wrote:
 On Thu, Dec 13, 2007 at 04:16:29PM +0100, Andi Kleen wrote:
  On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
   
   Ok, new patch attached, taking into account Andi's request for a cleaner 
   method
  
  Sorry for not noticing that earlier, but was there a specific reason this 
  needs
  to be an early quirk at all? kexec can only happen after the standard 
  quirks ran.
  I think it should be fine as a standard late quirk.
  
  -Andi
  
 Early quirk seemed like the right thing to do to me.  Starting from boot up,
 this (mis)configuration by the bios can mean that come cpus just don't get
 interrupts.  I could imagine situations like serial console not working if the
 serial port interrupt was routed to a cpu that used extended APIC id.  I've
 never actually observed it happening, but making sure that all cpus were
 eligible to get interrupts early in the boot process made sense to me.
 
 Neil
 

Sorry to push on this, but do we have a consensus on this fix?  Andi, do you
still feel this needs to be a late quirk given my previous arguments?

Regards
Neil

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

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-17 Thread Indan Zupancic

Hi,

On Mon, December 17, 2007 01:40, Tetsuo Handa wrote:
 Hello.

 Indan Zupancic wrote:
 What prevents them from mounting tmpfs on top of /dev, bypassing your fs?
 Mandatory access control (MAC) prevents them from mounting tmpfs on top of
 /dev .
 MAC mediates namespace manipulation requests such as mount()/umount().

 Also, if they have root there are plenty of ways to prevent an administrator
 from logging in, e.g. using iptables or changing the password.
 MAC mediates execution of /sbin/iptables or /usr/bin/passwd .

 So, use of this filesystem alone is meaningless because
 attackers with root privileges can do what you are saying.
 But use of this filesystem with MAC is still valid because
 MAC can prevent attackers with root privileges from doing what you are saying.

If MAC can avoid all that, then why can't it also avoid tampering with /dev?
What security does your filesystem add at all, if it's useless without a MAC
doing
all the hard work?

I think you can better spend your time on read-only bind mounts.

Greetings,

Indan


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

Re: How to Switch DMA off for only one Harddisk at Kernelboot

2007-12-17 Thread Bartlomiej Zolnierkiewicz

On Monday 17 December 2007, Oliver Joa wrote:
 Hi,
 
 Alan Cox wrote:
 
 [...]
 
  For the current kernel and libata you can use libata.dma=3, and it will
  select DMA for disk (1) + CD (2) but not CF cards. With the older IDE it
  should be sufficient to use hda=nodma
 
 Thanks a lot, but it does not work:
 
 If I use libata.dma=3 I get the following:
 [0.00] Unknown boot option `libata.dma=3': ignoring
 
 And if I use hda=nodma:
 [0.00] ide_setup: hda=nodma -- BAD OPTION
 
 I use kernel 2.6.21.5.
 
 Any Idea?

hdx=nodma was added in 2.6.24-rc1, older kernels have only ide=nodma

Also ide=nodma may not work in older kernel with some buggy host drivers
(they were fixed in 2.6.24-rc1).

Bart
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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/1] IPN: Inter Process Networking

2007-12-17 Thread Ludovico Gardenghi

On Mon, Dec 17, 2007 at 04:10:19AM -0800, [EMAIL PROTECTED] wrote:

 if you are talking network connections between virtual systems, then the 
 exiting tap interfaces would seem to do everything you are looking for. you 
 can add them to bridges, route between them, filter traffic between them 
 (at whatever layer you want with netfilter), use multicast, etc as you 
 would any real interface.

 if, however, you are talking about non-network communications (your example 
 of sending raw video frames across the interface), and want multiple 
 processes to receive them, this sounds like exactly the thing that splice 
 was designed to do, distribute data to multiple recipiants simultaniously 
 and efficiantly.

I'll try to explain.

Our first interest was to be able to interconnect virtual, real, and partial
virtual machines. We developed VDE for this, it's a user-level L2
switch. Specific as it may be, it's quite popular as a simple but
flexible tool. It can interconnect UML, Qemu, UMView, slirp, everything that
can be connected to a tap interface, etc.

So, you say, it's a networking issue and we could live with tun/tap.
There's a major point here: at present, dealing with tun/tap, bridges,
routing is quite difficult if you are a *regular* user with *no*
capabilites at all. You have tun/tap persistency and association to a
specific user (or group, recently), at most. That's good - we don't want
regular users to mess with global networking rules and settings.

Think of a bunch of etherogeneous virtual machines, partial virtual
machines (i.e. VMs where only a subset of system calls may be
virtualized or not depending on the parameters - that's the case of
View-OS) that must be interconnected and that may or may not have a
connection to a real network interface (maybe via a tunnel towards a
different machine). There's no need for administrator intervention here.
Why should an user have to ask root to create lots of tap interfaces for
him, bind them in a bridge and set up filtering/routing rules? What
would the list of interfaces become when different users asked for the
same thing at the same time?

You could define a specific interconnecting bus, but we've already have
it: ethernet. VDE comes in help as it allows regular users to build
distributed ethernet networks.

VDE works fine, but at present often results in a bottleneck because of
the high number of user-processes involved and user-kernel-user switches
needed in order to transfer a single ethernet frame. Moving the core
inside the kernel would limit this problem and result in faster
communication with still no need for root intervention or global
namespace messing. (we're thinking if something can be done working with
containers or similar structures, both for networking and partial
virtualization, but that's another topic).

So we started thinking how to use existing kernel structures, and we
concluded that:

 - no existing kernel structures appeared to be optimal for this work;
 - if we've had to design a new structure, it would have been more
   useful if we tried to be as more general as we could.

At present we're still focused on networking and other applications are
just examples, but we thought that adding a general extensible multipoint
IPC family is quite better than adding the most specific solution to our
current problem.

Maybe people with experience in other fields may tell us if there are
other problems that can be resolved, or optimized, or simply made
simpler, with IPN. Maybe our proposal is not the best as for interface
and semantics. But we feel that it may fill an empty space in the
available IPC mechanisms with a quite simple but powerful approach.

 for a new family to be valuble, you need to show what it does that isn't 
 available in existing families.

Is it more acceptable to add a new address family or to add features
to existing ones? (my question is purely informative, I don't want to
sound sarcastic or whatever) For instance, someone proposed let's just
add access control to the netlink family. It seems a though work. 

You proposed splice, other have proposed multicast or netlink. If I have
understood correctly, splice helps in copying data to different
destinations in a very fast way. But it needs a userspace program that
receives data, iterates on fds and splices the data out, calling a
syscall for each destination.  syscall calling may have become very fast
but we still notice slowdowns due to the reasons I've explained before.

--- (the following is not related to IPN but i wanted to answer this too)

 I'm not familiar enough with ptrace vs utrace to know this argument. but I 
 haven't heard any of the virtualization people complaining about the 
 existing interfaces. They seem to have been happily useing them for a 
 number of years.

ptrace has a number of drawbacks that have been partially addressed
adding flags and parameters for cheating and obtaining better
performances. It's *slow* expecially if you want to

Re: [patch 1/2] echoaudio semaphore to mutex

2007-12-17 Thread Takashi Iwai

At Sun, 09 Dec 2007 13:15:10 -0400,
Kevin Winchester wrote:
 
 Convert the semaphore to a mutex in echoaudio.c
 
 Signed-off-by: Kevin Winchester [EMAIL PROTECTED]

It was already fixed on ALSA tree :)

Thanks anyway.


Takashi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] drivers/cdrom/cdrom.c: simplify logic in cdrom_release()

2007-12-17 Thread Borislav Petkov

---
From: Borislav Petkov [EMAIL PROTECTED]

Simplify logic in cdrom_release() without semantical change.

Signed-off-by: Borislav Petkov [EMAIL PROTECTED]

--

 drivers/cdrom/cdrom.c |   17 +
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index af05610..037d4ec 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -1206,25 +1206,26 @@ int check_for_audio_disc(struct cdrom_device_info * cdi,
return 0;
 }
 
-/* Admittedly, the logic below could be performed in a nicer way. */
 int cdrom_release(struct cdrom_device_info *cdi, struct file *fp)
 {
struct cdrom_device_ops *cdo = cdi-ops;
int opened_for_data;
 
-   cdinfo(CD_CLOSE, entering cdrom_release\n); 
+   cdinfo(CD_CLOSE, entering cdrom_release\n);
 
if (cdi-use_count  0)
cdi-use_count--;
-   if (cdi-use_count == 0)
+
+   if (cdi-use_count == 0) {
cdinfo(CD_CLOSE, Use count for \/dev/%s\ now zero\n, 
cdi-name);
-   if (cdi-use_count == 0)
cdrom_dvd_rw_close_write(cdi);
-   if (cdi-use_count == 0 
-   (cdo-capability  CDC_LOCK)  !keeplocked) {
-   cdinfo(CD_CLOSE, Unlocking door!\n);
-   cdo-lock_door(cdi, 0);
+
+   if ((cdo-capability  CDC_LOCK)  !keeplocked) {
+   cdinfo(CD_CLOSE, Unlocking door!\n);
+   cdo-lock_door(cdi, 0);
+   }
}
+
opened_for_data = !(cdi-options  CDO_USE_FFLAGS) ||
!(fp  fp-f_flags  O_NONBLOCK);
 
-- 
Regards/Gruß,
Boris.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Possible fix for lockup in drop_caches

2007-12-17 Thread richard

Andrew Morton wrote:
 On Mon, 3 Dec 2007 16:52:47 +0300
 Denis V. Lunev [EMAIL PROTECTED] wrote:
 
 There is a AB-BA deadlock regarding drop_caches sysctl. Here are the
code
 paths:

snip...

 One way to fix jbd (and jbd2) would be:
 
 static void __journal_temp_unlink_buffer(struct journal_head *jh,
   struct buffer_head **bh_to_dirty)
 {
   *bh_to_dirty = NULL;
   ...
   if (test_clear_buffer_jbddirty(bh))
   *bh_to_dirty = bh;
 }
 
 {
   struct buffer_head *bh_to_dirty;/* probably needs
uninitialized_var() */
 
   ...
   __journal_temp_unlink_buffer(jh, bh_to_dirty);
   ...
   jbd_mark_buffer_dirty(bh_to_dirty);
   brelse(bh_to_dirty);
   ...
 }
 
 static inline void jbd_mark_buffer_dirty(struct buffer_head *bh)
 {
   if (bh)
   mark_buffer_dirty(bh);
 }
 
 
 --
Hi Andrew,
here's an implementation of your suggested approach for jbd.

Without this patch my test-case will lockup in 3 to 5 iterations, with
the patch I have completed 96+ runs.

I don't see any significant difference in write performance with this
patch applied. Subjectively I feel that my system is more responsive
when under heavy write loads but I don't have data to back that up, so
it might just be wishful thinking on my part!   

I've tested this on AMD 64x2 SMP 2.6.24-rc*

the patch is against 2.6.24-rc5.

Cheers
Richard

 fs/jbd/commit.c  |   19 +++---
 fs/jbd/transaction.c |   66 +++
 include/linux/jbd.h  |   11 ++--
 3 files changed, 70 insertions(+), 26 deletions(-)

commit 5b3824aa42a07682777836814fc7d1882416c6d3
Author: Richard Kennedy [EMAIL PROTECTED]
Date:   Mon Dec 17 12:05:36 2007 +

fix lockup in when calling drop_caches

calling /proc/sys/vm/drop_caches can hang due to a AB/BA lock dependency
between j_list_lock and the inode_lock. This patch moves the redirtying of 
the buffer head out
from under the j_list_lock.

based on a suggestion by Andrew Morton.

Signed-off-by: Richard Kennedy [EMAIL PROTECTED]

diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
index 610264b..9115b5d 100644
--- a/fs/jbd/commit.c
+++ b/fs/jbd/commit.c
@@ -181,6 +181,7 @@ static void journal_submit_data_buffers(journal_t *journal,
int locked;
int bufs = 0;
struct buffer_head **wbuf = journal-j_wbuf;
+   struct buffer_head *dirty_bh;
 
/*
 * Whenever we unlock the journal and sleep, things can get added
@@ -254,7 +255,8 @@ write_out_data:
put_bh(bh);
} else {
BUFFER_TRACE(bh, writeout complete: unfile);
-   __journal_unfile_buffer(jh);
+   __journal_unfile_buffer(jh, dirty_bh);
+   jbd_mark_buffer_dirty(dirty_bh);
jbd_unlock_bh_state(bh);
if (locked)
unlock_buffer(bh);
@@ -296,6 +298,7 @@ void journal_commit_transaction(journal_t *journal)
int first_tag = 0;
int tag_flag;
int i;
+   struct buffer_head *dirty_bh;
 
/*
 * First job: lock down the current transaction and wait for
@@ -453,7 +456,9 @@ void journal_commit_transaction(journal_t *journal)
continue;
}
if (buffer_jbd(bh)  jh-b_jlist == BJ_Locked) {
-   __journal_unfile_buffer(jh);
+   struct buffer_head *dirty_bh;
+   __journal_unfile_buffer(jh, dirty_bh);
+   jbd_mark_buffer_dirty(dirty_bh);
jbd_unlock_bh_state(bh);
journal_remove_journal_head(bh);
put_bh(bh);
@@ -833,7 +838,12 @@ restart_loop:
JBUFFER_TRACE(jh, add to new checkpointing trans);
__journal_insert_checkpoint(jh, commit_transaction);
JBUFFER_TRACE(jh, refile for checkpoint writeback);
-   __journal_refile_buffer(jh);
+   __journal_refile_buffer(jh, dirty_bh);
+   if (dirty_bh) {
+   spin_unlock(journal-j_list_lock);
+   jbd_mark_buffer_dirty(dirty_bh);
+   spin_lock(journal-j_list_lock);
+   }
jbd_unlock_bh_state(bh);
} else {
J_ASSERT_BH(bh, !buffer_dirty(bh));
@@ -845,7 +855,8 @@ restart_loop:
 * disk and before we process the buffer on BJ_Forget
 * list. */
JBUFFER_TRACE(jh, refile or unfile freed buffer);
-   __journal_refile_buffer(jh);
+   /* As !jbddirty dirty_bh will always be null so we can 
ignore it */
+

Re: RFC: remove __read_mostly

2007-12-17 Thread Andi Kleen

 So...  once we've moved all read-mostly variables into __read_mostly, what
 is left behind in bss?

I had already covered that in the next paragraph which you conveniently
snipped :)

Anyways I suspect the right solution for that would be more classes
of variables for even better grouping.

And for really often writen variables cache line padding is probably a good
idea.

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.


On 17-12-07 11:57, Ingo Molnar wrote:

thanks Rene! I've added your patch to x86.git. I changed a few things 
ontop of it, see the additional changelog and delta patch below.


appropriated it, more. Definitely not going to forgive you for deleting 
that comment.



 void native_io_delay(void)
 {
-   io_delay();
+   switch (io_delay_type) {


That's the clumsy bit. native_io_delay() used to be an inline outb, now it's 
a switch. Yes, sure, versus an indirect call it's not actually worse, except 
 as an uglification.



-#ifndef CONFIG_UDELAY_IO_DELAY
-static int __init dmi_alternate_io_delay_port(const struct dmi_system_id *id)
+static int __init dmi_io_delay_0xed_port(const struct dmi_system_id *id)
 {
-   printk(KERN_NOTICE %s: using alternate I/O delay port\n, id-ident);
-   io_delay = alternate_io_delay;
+   printk(KERN_NOTICE %s: using 0xed I/O delay port\n, id-ident);
+   io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
+
return 0;
 }


This isn't correct. DMI shouldn't override the CONFIG choice or someone with 
matching DMI will have a defective CONFIG option. That's why I put all of it 
inside #ifndef.


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/

Re: INITIO scsi driver fails to work properly

2007-12-17 Thread Boaz Harrosh

On Mon, Dec 17 2007 at 13:41 +0200, Filippos Papadopoulos [EMAIL PROTECTED] 
wrote:
 On Dec 17, 2007 1:18 PM, Andrew Morton [EMAIL PROTECTED] wrote:
 On Mon, 17 Dec 2007 11:39:47 +0200 Filippos Papadopoulos [EMAIL 
 PROTECTED] wrote:

 Hi,
 I have got an INITIO 9100 UW SCSI Controller with an IBM
 IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
 Currently i have SUSE 10.1 (Kernel 2.6.16).

 I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
 OpenSUSE 11.0 Alpha 0  (kernel 2.6.24-rc4) but although the initio
 driver
 gets loaded during the installation process, yast reports that no hard
 disk is found. I believe that this isnt a bug in suse's yast but a
 problem
 in the initio scsi driver because i also tried to install Fedora 8
 (kernel 2.6.23) with the same problem.
 I have seen the relevant thread Conflict when loading initio driver
 and i suppose that the initio driver isnt fixed yet.
 I can help testing the new patches in the initio driver if someone is
 interested.
 initio doesn't seem to have a maintainer...

 Are you able to identify any earlier kernel which worked OK?

 
 I have this PC configuration since 2002. The initio driver worked
 perfectly with 2.4 kernel series.
 With the release of 2.6 kernel series the driver had been marked as
 BROKEN and fixed at 2.6.9
 (see at 
 http://www.gossamer-threads.com/lists/linux/kernel/482582?search_string=SCSI%20updates%20for%202.6.9;#482582
   Christoph Hellwig  -don't mark the initio 9100 driver broken)
 
 
 Maybe it's a new device?  If you can get the `lspci -vvxx' output
 for that device we can take a look.

 
 No its not a new device.
 -

I have found one problem. Please try patch [2] below and report.
If it still fails try to enable debugging by setting with patch [1]
these values at top of drivers/scsi/initio.c. And send dmsgs.

Boaz



patch [1]


diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 4c4465d..61edcd2 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -138,10 +138,10 @@ static struct pci_device_id i91u_pci_devices[] = {
 };
 MODULE_DEVICE_TABLE(pci, i91u_pci_devices);
 
-#define DEBUG_INTERRUPT 0
-#define DEBUG_QUEUE 0
-#define DEBUG_STATE 0
-#define INT_DISC   0
+#define DEBUG_INTERRUPT 1
+#define DEBUG_QUEUE 1
+#define DEBUG_STATE 1
+#define INT_DISC   1
 
 /*--- forward references ---*/
 static struct scsi_ctrl_blk *initio_find_busy_scb(struct initio_host * host, 
u16 tarlun);


---
patch [2]
---
git-diff --stat -p
 drivers/scsi/initio.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 4c4465d..61595f6 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2616,6 +2616,7 @@ static void initio_build_scb(struct initio_host * host, 
struct scsi_ctrl_blk * c
scsi_for_each_sg(cmnd, sglist, cblk-sglen, i) {
sg-data = cpu_to_le32((u32)sg_dma_address(sglist));
total_len += sg-len = 
cpu_to_le32((u32)sg_dma_len(sglist));
+   sg++;
}
 
cblk-buflen = (scsi_bufflen(cmnd)  total_len) ?


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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]: Atmel Serial Console interrupt handler splitup

2007-12-17 Thread Haavard Skinnemoen

On Fri, 14 Dec 2007 12:46:09 +0100
Remy Bohmer [EMAIL PROTECTED] wrote:

 Hello Andrew,
 
 So, to come to a conclusion about this complex patch series, I
 attached all the latest versions to this mail. The latest patches from
 yesterday including inline are also included to make the set complete.
 
 So, this is the order in which the patches should be installed:
 1) atmel_serial_cleanup.patch
 2) atmel_serial_irq_splitup.patch
 3) NEW: optional:  add-atmel-serial-dma.patch, this merged the DMA
 code (from Chip Coldwell) in your 2.6.23 patch back on top of this
 series. Because the AT32 bug is not been fixed for a very long time, I
 do not expect it to be fixed soon, so I think a reordering is better
 to make preempt-RT work on AT91.

I'll give it a shot, but first I have some comments on your other
patches.

Btw, it would be nice if patches that affect more or less
architecture-independent drivers were posted to linux-kernel (added to
Cc.)

Also, it would be easier to review if you posted just one patch per
e-mail. I'm going to cut  paste a bit from your attachments.

 4) For RT only: atmel_serial_irqf_nodelay.patch can be applied
 anywhere after 1 and 2

I'll ignore this for now.

 +#define lread(port)  __raw_readl(port)
 +#define lwrite(v, port)  __raw_writel(v, port)

Why is this necessary, and what does 'l' stand for?

 - struct uart_portuart;   /* uart */
 - struct clk  *clk;   /* uart clock */
 - unsigned short  suspended;  /* is port suspended? */
 - int break_active;   /* break being received */
 + struct uart_portuart;   /* uart */
 + struct clk  *clk;   /* uart clock */
 + unsigned short  suspended;  /* is port suspended? */
 + int break_active;   /* break being received */

Looks like you're adding one or more spaces before each TAB here. Why
is that an improvement?

 static void atmel_stop_tx(struct uart_port *port)
  {
 - struct atmel_uart_port *atmel_port = (struct atmel_uart_port *) port;
 -
   UART_PUT_IDR(port, ATMEL_US_TXRDY);
  }
  
 @@ -214,8 +216,6 @@ static void atmel_stop_tx(struct uart_po
   */
  static void atmel_start_tx(struct uart_port *port)
  {
 - struct atmel_uart_port *atmel_port = (struct atmel_uart_port *) port;
 -
   UART_PUT_IER(port, ATMEL_US_TXRDY);
  }
  
 @@ -224,8 +224,6 @@ static void atmel_start_tx(struct uart_p
   */
  static void atmel_stop_rx(struct uart_port *port)
  {
 - struct atmel_uart_port *atmel_port = (struct atmel_uart_port *) port;
 -
   UART_PUT_IDR(port, ATMEL_US_RXRDY);
  }

These conflict with David Brownell's atmel_serial build warnings
begone patch which was merged into mainline a few weeks ago.

 static void atmel_enable_ms(struct uart_port *port)
  {
 - UART_PUT_IER(port, ATMEL_US_RIIC | ATMEL_US_DSRIC | ATMEL_US_DCDIC | 
 ATMEL_US_CTSIC);
 + UART_PUT_IER(port,
 +  ATMEL_US_RIIC | ATMEL_US_DSRIC | ATMEL_US_DCDIC |
 +  ATMEL_US_CTSIC);

This looks a bit funny...IMO it would be better to keep a few of them
on the first line and indent the next line with an extra tab. But I'm
not going to be difficult about it if it conforms with the existing
style in the driver.

  /*
 + * receive interrupt handler.
 + */
 +static inline void
 +atmel_handle_receive(struct uart_port *port, unsigned int pending)

Please drop inline here. The compiler will do it automatically if it
has only one caller, and if it at some point gets several callers, we
might not want to inline it after all.

 +{
 + struct atmel_uart_port *atmel_port = (struct atmel_uart_port *)port;
 +
 + /* Interrupt receive */
 + if (pending  ATMEL_US_RXRDY)
 + atmel_rx_chars(port);
 + else if (pending  ATMEL_US_RXBRK) {
 + /*
 + * End of break detected. If it came along
 + * with a character, atmel_rx_chars will
 + * handle it.
 + */

Looks like the indentation got messed up here.

 + UART_PUT_CR(port, ATMEL_US_RSTSTA);
 + UART_PUT_IDR(port, ATMEL_US_RXBRK);
 + atmel_port-break_active = 0;
 + }
 +}
 +
 +/*
 + * transmit interrupt handler.
 + */
 +static inline void
 +atmel_handle_transmit(struct uart_port *port, unsigned int pending)
 +{
 + /* Interrupt transmit */
 + if (pending  ATMEL_US_TXRDY)
 + atmel_tx_chars(port);
 +}
 +
 +/*
 + * status flags interrupt handler.
 + */
 +static inline void
 +atmel_handle_status(struct uart_port *port, unsigned int pending,
 + unsigned int status)
 +{
 + /* TODO: All reads to CSR will clear these interrupts! */
 + if (pending  ATMEL_US_RIIC)
 + port-icount.rng++;
 + if (pending  ATMEL_US_DSRIC)
 + port-icount.dsr++;
 + if (pending  ATMEL_US_DCDIC)
 +

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread shyam_iyer

Hello,

I am seeing that this doesn't fix a Dell PowerEdge T105 which has the CK804 
chipset.

This system has a HL-DT-ST DVD-ROM (See dmesg with this posting) attached to 
the sata ports and has 8Gb physical memory.

The SATA DVD rom gets detected but any I/O like dd or mount is not successful.

If I reduce the memory with mem=4Gb or disable the adma mode by passing 
adma=0, I am able to mount the media or do I/O.

Dmesg output -

Linux version 2.6.24-rc5-default ([EMAIL PROTECTED]) (gcc version 4.1.2 
20070115 (prerelease) (SUSE Linux)) #2 SMP Thu Dec 13 15:38:25 IST 2007
Command line: root=/dev/disk/by-id/scsi-3600508e03ad8e2c732a09d08-part3 
vga=0x31a resume=/dev/sda2 splash=verbose showopts
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009cc00 (usable)
 BIOS-e820: 0009cc00 - 000a (reserved)
 BIOS-e820: 000cc000 - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 8000 (reserved)
 BIOS-e820: 8000 - cff0 (usable)
 BIOS-e820: cff0 - cff0a000 (ACPI data)
 BIOS-e820: cff0a000 - cff8 (ACPI NVS)
 BIOS-e820: cff8 - d000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
 BIOS-e820: 0001 - 00023000 (usable)
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
end_pfn_map = 2293760
DMI present.
ACPI: RSDP 000F7AE0, 0014 (r0 PTLTD )
ACPI: RSDT CFF064D5, 004C (r1 DELL   PE_SC3604 DELL0)
ACPI: FACP CFF09906, 0074 (r1 DELL   PE_SC3604 DELLF4240)
ACPI: DSDT CFF06521, 33E5 (r1 DELL   PE_SC3604 MSFT  10E)
ACPI: FACS CFF0AFC0, 0040
ACPI: TCPA CFF0997A, 0032 (r1 Phoeni  x604  TL 0)
ACPI: SLIC CFF099AC, 0176 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SPCR CFF09B22, 0050 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SRAT CFF09B72, 00C8 (r1 AMDHAMMER604 AMD 1)
ACPI: SSDT CFF09C3A, 02CC (r1 AMDPOWERNOW  604 AMD 1)
ACPI: MCFG CFF09F06, 003C (r1 PTLTDMCFG604  LTP0)
ACPI: HPET CFF09F42, 0038 (r1 PTLTD  HPETTBL   604  LTP1)
ACPI: APIC CFF09F7A, 005E (r1 PTLTD  APIC604  LTP0)
ACPI: BOOT CFF09FD8, 0028 (r1 PTLTD  $SBFTBL$  604  LTP1)
SRAT: PXM 0 - APIC 0 - Node 0
SRAT: PXM 0 - APIC 1 - Node 0
SRAT: Node 0 PXM 0 0-a
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-d000
Entering add_active_range(0, 0, 156) 1 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-23000
Entering add_active_range(0, 0, 156) 3 entries of 3200 used
Entering add_active_range(0, 256, 524272) 3 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 -00023000
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  2293760
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
0:0 -  156
0:  256 -   524272
0:   524288 -   851712
0:  1048576 -  2293760
On node 0 totalpages: 2096780
  DMA zone: 96 pages used for memmap
  DMA zone: 2540 pages reserved
  DMA zone: 1360 pages, LIFO batch:0
  DMA32 zone: 24480 pages used for memmap
  DMA32 zone: 823120 pages, LIFO batch:31
  Normal zone: 29184 pages used for memmap
  Normal zone: 1216000 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x8008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10de8201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009c000 - 0009d000
swsusp: Registered nosave memory region: 0009d000 -

Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)

2007-12-17 Thread shyam_iyer

Hello,

I am seeing that this doesn't fix a Dell PowerEdge T105 which has the CK804 
chipset.

This system has a HL-DT-ST DVD-ROM (See dmesg with this posting) attached to 
the sata ports and has 8Gb physical memory.

The SATA DVD rom gets detected but any I/O like dd or mount is not successful.

If I reduce the memory with mem=4Gb or disable the adma mode by passing 
adma=0, I am able to mount the media or do I/O.

Dmesg output -

Linux version 2.6.24-rc5-default ([EMAIL PROTECTED]) (gcc version 4.1.2 
20070115 (prerelease) (SUSE Linux)) #2 SMP Thu Dec 13 15:38:25 IST 2007
Command line: root=/dev/disk/by-id/scsi-3600508e03ad8e2c732a09d08-part3 
vga=0x31a resume=/dev/sda2 splash=verbose showopts
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009cc00 (usable)
 BIOS-e820: 0009cc00 - 000a (reserved)
 BIOS-e820: 000cc000 - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 8000 (reserved)
 BIOS-e820: 8000 - cff0 (usable)
 BIOS-e820: cff0 - cff0a000 (ACPI data)
 BIOS-e820: cff0a000 - cff8 (ACPI NVS)
 BIOS-e820: cff8 - d000 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
 BIOS-e820: 0001 - 00023000 (usable)
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
end_pfn_map = 2293760
DMI present.
ACPI: RSDP 000F7AE0, 0014 (r0 PTLTD )
ACPI: RSDT CFF064D5, 004C (r1 DELL   PE_SC3604 DELL0)
ACPI: FACP CFF09906, 0074 (r1 DELL   PE_SC3604 DELLF4240)
ACPI: DSDT CFF06521, 33E5 (r1 DELL   PE_SC3604 MSFT  10E)
ACPI: FACS CFF0AFC0, 0040
ACPI: TCPA CFF0997A, 0032 (r1 Phoeni  x604  TL 0)
ACPI: SLIC CFF099AC, 0176 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SPCR CFF09B22, 0050 (r1 DELL   PE_SC3604 PTL 1)
ACPI: SRAT CFF09B72, 00C8 (r1 AMDHAMMER604 AMD 1)
ACPI: SSDT CFF09C3A, 02CC (r1 AMDPOWERNOW  604 AMD 1)
ACPI: MCFG CFF09F06, 003C (r1 PTLTDMCFG604  LTP0)
ACPI: HPET CFF09F42, 0038 (r1 PTLTD  HPETTBL   604  LTP1)
ACPI: APIC CFF09F7A, 005E (r1 PTLTD  APIC604  LTP0)
ACPI: BOOT CFF09FD8, 0028 (r1 PTLTD  $SBFTBL$  604  LTP1)
SRAT: PXM 0 - APIC 0 - Node 0
SRAT: PXM 0 - APIC 1 - Node 0
SRAT: Node 0 PXM 0 0-a
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-d000
Entering add_active_range(0, 0, 156) 1 entries of 3200 used
Entering add_active_range(0, 256, 524272) 1 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-23000
Entering add_active_range(0, 0, 156) 3 entries of 3200 used
Entering add_active_range(0, 256, 524272) 3 entries of 3200 used
Entering add_active_range(0, 524288, 851712) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 2293760) 3 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 -00023000
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  2293760
Movable zone start PFN for each node
early_node_map[4] active PFN ranges
0:0 -  156
0:  256 -   524272
0:   524288 -   851712
0:  1048576 -  2293760
On node 0 totalpages: 2096780
  DMA zone: 96 pages used for memmap
  DMA zone: 2540 pages reserved
  DMA zone: 1360 pages, LIFO batch:0
  DMA32 zone: 24480 pages used for memmap
  DMA32 zone: 823120 pages, LIFO batch:31
  Normal zone: 29184 pages used for memmap
  Normal zone: 1216000 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x8008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x10de8201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009c000 - 0009d000
swsusp: Registered nosave memory region: 0009d000 -

Re: RFC: remove __read_mostly

2007-12-17 Thread Andi Kleen

On Mon, Dec 17, 2007 at 03:07:43AM -0800, Andrew Morton wrote:
 On Mon, 17 Dec 2007 11:53:36 +0100 Eric Dumazet [EMAIL PROTECTED] wrote:
 
  n Mon, 17 Dec 2007 02:33:39 -0800
  Andrew Morton [EMAIL PROTECTED] wrote:
  
   On Fri, 14 Dec 2007 01:33:45 +0100 Andi Kleen [EMAIL PROTECTED] wrote:
   
Kyle McMartin [EMAIL PROTECTED] writes:

 I'd bet, in the __read_mostly case at least, that there's no
 improvement in almost all cases.

I bet you're wrong. Cache line behaviour is critical, much more
than pipeline behaviour (which unlikely affects). That is because
if you eat a cache miss it gets really expensive, which e.g.
a mispredicted jump is relatively cheap in comparison. We're talking
one or more orders of magnitude.
   
   So...  once we've moved all read-mostly variables into __read_mostly, what
   is left behind in bss?
   
   All the write-often variables.  All optimally packed together to nicely
   maximise cacheline sharing.
  
  This is why it's important to group related variables together, so that 
  they share
  same cacheline.
 
 Not feasible.  The linker is (I believe) free to place them anywhere it
 likes unless we go and aggregate them in a struct.

It won't normally though (they are put linear for each object file)
and if you really want to make sure you can always use a special section.

 The insidious thing about this is that is is highly dependent upon
 compiler/linker version and upon kernel config.  So performance differences

I'm not aware of the order of global variables changing that much.
Especially the linker seems to keep it rather stable.

 end up with a better result: all those read-mostly, read-rarely variables (and
 there are a lot of those) could be very usefully deployed by packing them
 in between the write-often variables.
 
 It's crying out for a performance-guided solution.

My problem with profile feedback is that it will make it impossible
to ever recreate kernel binaries after the fact. So decoding of random
oopses would become much harder.

-Andi


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

Re: INITIO scsi driver fails to work properly

2007-12-17 Thread Boaz Harrosh

On Mon, Dec 17 2007 at 14:18 +0200, Boaz Harrosh [EMAIL PROTECTED] wrote:
On Mon, Dec 17 2007 at 13:41 +0200, Filippos Papadopoulos [EMAIL
PROTECTED] wrote:
On Dec 17, 2007 1:18 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 11:39:47 +0200 Filippos Papadopoulos [EMAIL
PROTECTED] wrote:

Hi,
I have got an INITIO 9100 UW SCSI Controller with an IBM
IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
Currently i have SUSE 10.1 (Kernel 2.6.16).

Are you able to identify any earlier kernel which worked OK?

Maybe it's a new device? If you can get the `lspci -vvxx' output
for that device we can take a look.

No its not a new device.
-

I have found one problem. Please try patch [2] below and report.
If it still fails try to enable debugging by setting with patch [1]
these values at top of drivers/scsi/initio.c. And send dmsgs.

Boaz

I forgot to ask. 2.6.22 should work. If still fails could you try
this 2.6.22.xx kernel?

Boaz

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

Re: Top kernel oopses/warnings this week

2007-12-17 Thread Jon Masters


On Sun, 2007-12-16 at 21:51 -0500, Dave Jones wrote:
 On Sat, Dec 15, 2007 at 04:49:05PM +0100, Stefan Richter wrote:
  
   Reports about tainted kernels have arguably less value.  It would be
   good to hide such reports until a report of the same oops in an
   untainted kernel was found.
  
 I disagree with this.  It's useful to have a we've seen this before,
 and every time, it was tainted with xyz module datapoint, especially
 if no untainted copies of that oops turn up.

+1

In fact, that's even more useful in many cases, if it helps demonstrate
that the oops is associated with a particular buggy binary driver. I can
see a lot of potentially interesting statistics coming from that too.

Jon.


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

Re: RFC: remove __read_mostly

2007-12-17 Thread Adrian Bunk

On Mon, Dec 17, 2007 at 01:15:56PM +0100, Andi Kleen wrote:
  So...  once we've moved all read-mostly variables into __read_mostly, what
  is left behind in bss?
 
 I had already covered that in the next paragraph which you conveniently
 snipped :)
 
 Anyways I suspect the right solution for that would be more classes
 of variables for even better grouping.
...

Is there any way to tell gcc that it's still allowed to omit the 
variable when it's able to prove it's read-only?

My basic fear with all the __read_mostly, immediate values,... stuff is 
that it might interfere with gcc optimizations.

 -Andi

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: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl

2007-12-17 Thread Andi Kleen

On Mon, Dec 17, 2007 at 08:57:50AM +1100, Paul Mackerras wrote:
 Greg KH writes:
 
  Ok, sorry, it wasn't blindingly obvious that this was for pci sysfs
  devices that are mmaped, that makes a bit more sense.
  
  But I'd like to see what ioctl is wanted here first.
 
 I believe the ioctl would be to set whether the mapping goes to I/O or
 memory space, 

x86 cannot really access IO space through mmap so no that wasn't planned

The main planned use was to get the translated bus address (after IOMMU)
for a mapping and to set the caching modes.

 So the alternative to the ioctl would be to have multiple files in
 sysfs, one per combination of modes -- i.e., 4 files, or 3 if we
 exclude the I/O with write combining mode, which would be
 reasonable.

At least for the IOMMU translation case that wouldn't work.

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

Re: Option to disable AMD C1E (allows dynticks to work)

2007-12-17 Thread Eduard-Gabriel Munteanu

On Sun, 16 Dec 2007 06:29:57 -0800 (PST)
[EMAIL PROTECTED] wrote:

 On Dec 15, 2:20 am, Eduard-Gabriel Munteanu
 [EMAIL PROTECTED] wrote:
  On Fri, 14 Dec 2007 17:35:13 -0500
 
  But maybe someone with access to such hardware can tell us what
  happens: does he get C2/C3 power states under such circumstances?
 
 Hi,
 
 I have a nx6325 laptop with Turion 64 X2 CPU. So far I have had no
 success
 in getting NO_HZ to work on my box.
 
 I am a C coder, but have no experience in kernel hacking. However, I
 _really_ would
 like to help resolve this issue.
 
 It would be nice if You could give me any information on what/where to
 look for. Also,
 I would be happy to test any patches for this specific problem.
 
 Thanks,
 Cubris Zukilla, [EMAIL PROTECTED]

Hi,

The patch I submitted gets NOHZ working, but it doesn't improve power
savings. The power usage actually increases by 1 watt or so on my
laptop, because there are no other C-states higher than C1 available
and C1E needs to be disabled.

I wasn't asking for testers for this patch. Instead, my question was
related to those laptops that disable C1E on the first CPU, but not on
the second. Does the BIOS offer an option to disable C1E? Does the BIOS
fill higher C-states? Andi Kleen provided an answer to my question,
saying that AMD doesn't currently support higher C-states on multi-core
CPUs, but I was wondering whether this was an attempt on the laptop
vendor's part to provide this functionality or just an ugly bug.

There isn't much you could do. The problem is rooted quite deeply
inside Linux and I don't think this would be a beginner's task.
Moreover, there are lots of hardware quirks one must account for.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 V2] ipwireless_cs driver for 4G PC Card

2007-12-17 Thread Jiri Kosina

On Mon, 17 Dec 2007, Andrew Morton wrote:

  Andrew, what is your position on merging this into your 2.6.25 queue 
  please? David has fixed all the issues that came up during review, so 
  it seems to be that it's time for the driver to be merged during the 
  upcoming merge window. If you take it, I am perfectly fine with you 
  dropping the ipwireless_cs git tree from -mm lineup.
 I'd have thought that you'd merge it into git-ipwireless_cs.patch and that
 you would then take care of merging it into mainline at an appropriate
 time?

I'd normally send this through PCMCIA maintainer's tree, but as long as 
there is no such thing, I thought that merging through you is the best 
thing to do. I don't want to bother Linus with pull request for a single 
new driver.

Thanks,

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

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-17 Thread Tetsuo Handa

Hello.

Indan Zupancic wrote:
 If MAC can avoid all that, then why can't it also avoid tampering with /dev?

If MAC implementation handles filename and its attributes pair, this filesystem 
is not needed.
But I don't know MAC implementations that handle this pair.

SELinux's granularity is allow foo_t to create block device file in dev_t 
directory.
TOMOYO's granularity is allow foo to create block device file named /dev/sda1.
Both don't enforce filename and its attributes pair,
thus the attacker with root privilege can create fake device files
if he/she is permitted to create device files by MAC's policy.

It would be possible to handle this pair within MAC's policy
by expanding their policy syntaxes,
but offloading this handling on filesystem can make MAC's policy syntax simple
because filename and its attributes pairs are conventionally constant.
You won't let foo_t to create /dev/sda1 with block-8-1 attributes
and let bar_t to create /dev/sda1 with block-8-2 attributes, will you?
You don't want to describe attribute information to every entry in MAC's 
policy, do you?
It is redundant to describe this attribute enforcement information in MAC's 
policy
unless you want to break conventional filename and its attributes pairs.

 What security does your filesystem add at all, if it's useless without a MAC
 doing all the hard work?
Allow / partition to be mounted for read-only mode.
Allow /dev partition to be enforced filename and its attributes
to avoid /dev/null spoofing (create /dev/null as a regular file for 
eavesdropping purpose).

This filesystem adds filename and its attributes enforcement,
but it is overridable if this filesystem is used without MAC.
This filesystem adds unoverridable filename and its attributes enforcement
if this filesystem is used with MAC.

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.


On 17-12-07 04:35, H. Peter Anvin wrote:

Well, we probably should leave the possibility in to use 0x80 -- for one 
thing, we need to use 0x80 on 386, and there is always the possibility 
that the switch will have different timing properties on some or all 
machines.


Note that this doesn't require that a machine actually implements port 
0xf0 for FERR/IGNNE, it just requires that they don't use it for 
something else.


I would be rather inclined to try using port 0xf0 by default as long as 
family  3[*] (with fallback to port 0x80) at least experimentally (-mm).


Possible timing differences would be what worry me. 0x80 is well-known for 
its delay purposes, and frankly, I dont believe that one type of machine 
having a problem, which may very well have to be categorized a possibly BIOS 
fixable bug, is enough ground for switching everyone over to a different port


It's enough ground to look at not doing outputs at all AFAIC but that's more 
due to the outb being somewhat cheesy to start with which using a different 
port wouldn't change. But, on the other hand:


We *might* even be able to use port 0xf0 unconditionally in the setup 
code, since we're not using the FPU there (the only FPU instructions in 
the setup code are there to detect the FPU.)


One thing: although I believe most actual implementations of port 0xf0 
implement it as a strobe alone (data is ignored), all documentation I've 
found, including The Undocumented PC specifically says write 0x00 to 
this port.  This *could* mean there are platforms which use other 
values than 0x00 for other hacks.


The Intel PIIX/PIIX3 datasheet confirms that the data is of no consequence, 
but yes, most documentation talks about 0.


The PIIX/PIIX3 datasheet also says that both reads and writes flow through 
to the ISA bus, while for port 0x80 only writes do, and reads do not.


I do not know how universal that is, but _reading_ port 0xf0 might in fact 
be sensible then? And should even work on a 386/387 pair? (I have a 386/387 
in fact, although I'd need to dig it up).


Versus the out it has the al clobber disadvantage, but givne that we're by 
now seem to be talking about out of line switch() native_io_delays anyways, 
that's not much of a problem anymore...



[*] The following statements are equivalent:
- family  3.
- CR0.NE is settable.
- EFLAGS.AC is settable.


For the boot code, I gather (which could I suppose then also plug in the 
delay port in the zero page or somewhere for use by the kernel proper? I 
don't know how/if these bits communicate).


But, well, _reading_ port 0xf0 sounds promising across the board and low 
risk replacement _if_ teh PIIX/PIIX3 behaviour is as guaranteed as the port 
0x80 behaviour...


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/

lockdep hashes

2007-12-17 Thread Cyrill Gorcunov

Hi Ingo,

i'm quite sorry for annoying you with my stupid question but
i don't know whom to ask about lockdep hashes (you're the
author right?). Ingo look the code has

#define iterate_chain_key(key1, key2) \
(((key1)  MAX_LOCKDEP_KEYS_BITS) ^ \
((key1)  (64-MAX_LOCKDEP_KEYS_BITS)) ^ \
(key2))

but from where this function math is taken? How dod you find
it? (I read Knuth about hash functions and about prime numbers).
Or this is an experience who shows you the right hashing formula?
Could you point me in which direction i shoul to digg to understand this?

Cyrill

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

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-17 Thread Al Boldi

Indan Zupancic wrote:
 On Mon, December 17, 2007 01:40, Tetsuo Handa wrote:
  So, use of this filesystem alone is meaningless because
  attackers with root privileges can do what you are saying.
  But use of this filesystem with MAC is still valid because
  MAC can prevent attackers with root privileges from doing what you are
  saying.

 If MAC can avoid all that, then why can't it also avoid tampering with
 /dev? What security does your filesystem add at all, if it's useless
 without a MAC doing all the hard work?

I think the answer is obvious:  Tetsuo wants to add functionality that the 
MACs are missing.  So, instead of adding this functionality per MAC, he 
proposes to add it as ground work, to be combined with any MAC.

 I think you can better spend your time on read-only bind mounts.

That would be too coarse.


Thanks!

--
Al

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

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

2007-12-17 Thread Parag Warudkar

On Dec 17, 2007 3:05 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:

 On Sun, 16 Dec 2007, Parag Warudkar wrote:

  On Dec 16, 2007 12:15 AM, Parag Warudkar [EMAIL PROTECTED] wrote:
   On Sat, 15 Dec 2007, Parag Warudkar wrote:
  
I will run it for a little longer just to be sure - but I don't think 
it
will be a problem.
  
   No problems for last 10 hours - I consider this fixed.
  
 
  Arghh - spoke 8 hours too soon. I left it running overnight and
  morning I see a bunch of softlockups - so NO NOT FIXED.
 
  Parag
 
  BUG: soft lockup - CPU#1 stuck for 13s! [swapper:0]
 
  Pid: 0, comm: swapper Not tainted (2.6.24-rc5 #21)
  EIP: 0060:[c0533ca6] EFLAGS: 0206 CPU: 1
  EIP is at acpi_idle_enter_simple+0x166/0x1d0
  EAX: f7829f88 EBX: 0dab ECX: 0266 EDX: 
  ESI:  EDI: 00c056e5 EBP: 00c0493a ESP: f7829f88
   DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
  CR0: 8005003b CR2: 080f6c78 CR3: 00718000 CR4: 06d0
  DR0:  DR1:  DR2:  DR3: 
  DR6: 0ff0 DR7: 0400

 Sigh. You did not have the debug patch applied anymore, which printks
 the timer_list data ? Can you apply it again and provide the output
 please ?


This keeps getting more and more weird - This time I was running with
CONFIG_CPU_IDLE=N and I have ton of soft lockups after 14hr uptime.

The timer_list data for a few lockups is below. If you need the full
thing grab it from http://warudkars.net/messages.bz2 .

BUG: soft lockup - CPU#1 stuck for 12s! [kjournald:424]

Pid: 424, comm: kjournald Not tainted (2.6.24-rc5 #24)
EIP: 0060:[c04bbd57] EFLAGS: 0206 CPU: 1
EIP is at __journal_remove_journal_head+0x18/0xe8
EAX: dc75e1c0 EBX: dc75e1c0 ECX: f6d539f0 EDX: dc75e1f8
ESI: dc75e1f8 EDI: 0009 EBP: f712a000 ESP: f7157f28
 DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
CR0: 8005003b CR2: b7d18eb4 CR3: 37352000 CR4: 06d0
DR0:  DR1:  DR2:  DR3: 
DR6: 0ff0 DR7: 0400
 [c04b8680] __journal_unfile_buffer+0x8/0x11
 [c04bbe64] journal_put_journal_head+0x3d/0x4b
 [c04ba254] journal_commit_transaction+0x75d/0xbc9
 [c0428246] lock_timer_base+0x19/0x35
 [c04bcda0] kjournald+0xa2/0x1d0
 [c0430e29] autoremove_wake_function+0x0/0x35
 [c04bccfe] kjournald+0x0/0x1d0
 [c0430d63] kthread+0x38/0x5d
 [c0430d2b] kthread+0x0/0x5d
 [c0404a0f] kernel_thread_helper+0x7/0x10
 ===
Timer List Version: v0.3
HRTIMER_MAX_CLOCK_BASES: 2
now at 39080147128907 nsecs

cpu: 0
 clock 0:
  .index:  0
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset: 1197846065352886518 nsecs
active timers:
 clock 1:
  .index:  1
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset: 0 nsecs
active timers:
 #0: f7157dd4, tick_sched_timer, S:01, tick_nohz_stop_sched_tick, swapper/0
 # expires at 3908027200 nsecs [in 124871093 nsecs]
 #1: f7157dd4, it_real_fn, S:01, do_setitimer, syslogd/2522
 # expires at 3908647554 nsecs [in 6328414426 nsecs]
 #2: f7157dd4, hrtimer_wakeup, S:01, do_nanosleep, atd/3039
 # expires at 39332442305024 nsecs [in 252295176117 nsecs]
  .expires_next   : 3908032000 nsecs
  .hres_active: 1
  .nr_events  : 81214
  .nohz_mode  : 2
  .idle_tick  : 390780 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 9694501
  .idle_calls : 171123
  .idle_sleeps: 106664
  .idle_entrytime : 39080384013047 nsecs
  .idle_sleeptime : 38923743508612 nsecs
  .last_jiffies   : 9695101
  .next_jiffies   : 9695250
  .idle_expires   : 3907999600 nsecs
jiffies: 9695106

cpu: 1
 clock 0:
  .index:  0
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset: 1197846065352886518 nsecs
active timers:
 clock 1:
  .index:  1
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset: 0 nsecs
active timers:
 #0: f7157dd4, hrtimer_wakeup, S:01, do_nanosleep, crond/2946
 # expires at 39115730211364 nsecs [in 35583082457 nsecs]
 #1: f7157dd4, hrtimer_wakeup, S:01, do_nanosleep, smartd/3480
 # expires at 39641838017337 nsecs [in 561690888430 nsecs]
  .expires_next   : 3907999700 nsecs
  .hres_active: 1
  .nr_events  : 48789
  .nohz_mode  : 2
  .idle_tick  : 3906686500 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 9691717
  .idle_calls : 125065
  .idle_sleeps: 79815
  .idle_entrytime : 39079996603653 nsecs
  .idle_sleeptime : 38923914717954 nsecs
  .last_jiffies   : 9695000
  .next_jiffies   : 9695467
  .idle_expires   : 3908186400 nsecs
jiffies: 9695162


Tick Device: mode: 1
Clock Event Device: hpet
 max_delta_ns:   2147483647
 min_delta_ns:   3352
 mult:   61496110
 shift:  32
 mode:   3
 next_event: 3908070400 nsecs
 set_next_event: hpet_legacy_next_event
 set_mode:   hpet_legacy_set_mode
 event_handler:  tick_handle_oneshot_broadcast
tick_broadcast_mask: 0003
tick_broadcast_oneshot_mask: 0001


Tick Device: mode: 1
Clock Event Device: lapic
 max_delta_ns:   805378776
 min_delta_ns:   1440

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.


* Rene Herman [EMAIL PROTECTED] wrote:

 On 17-12-07 11:57, Ingo Molnar wrote:

 thanks Rene! I've added your patch to x86.git. I changed a few things 
 ontop of it, see the additional changelog and delta patch below.

 appropriated it, more. [...]

huh?

 [...] Definitely not going to forgive you for deleting that comment.

Do you mean:

+/*
+ * High on a hill was a lonely goatherd
+ */

?

  void native_io_delay(void)
  {
 -io_delay();
 +switch (io_delay_type) {

 That's the clumsy bit. native_io_delay() used to be an inline outb, 
 now it's a switch. Yes, sure, versus an indirect call it's not 
 actually worse, except as an uglification.

the switch enableds the sysctl. I dont see the callback as in any way 
cleaner. (in fact it made things more inflexible.)

 -#ifndef CONFIG_UDELAY_IO_DELAY
 -static int __init dmi_alternate_io_delay_port(const struct dmi_system_id 
 *id)
 +static int __init dmi_io_delay_0xed_port(const struct dmi_system_id *id)
  {
 -printk(KERN_NOTICE %s: using alternate I/O delay port\n, id-ident);
 -io_delay = alternate_io_delay;
 +printk(KERN_NOTICE %s: using 0xed I/O delay port\n, id-ident);
 +io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
 +
  return 0;
  }

 This isn't correct. DMI shouldn't override the CONFIG choice or 
 someone with matching DMI will have a defective CONFIG option. That's 
 why I put all of it inside #ifndef.

no, the DMI quirk is just that: a quirk that makes boxes work. The DMI 
quirk takes precedence over just about any .config default, except an 
explicit boot-commandline override.

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

Re: INITIO scsi driver fails to work properly

2007-12-17 Thread Alan Cox

 initio doesn't seem to have a maintainer...
 
 Are you able to identify any earlier kernel which worked OK?
 
 Maybe it's a new device?  If you can get the `lspci -vvxx' output
 for that device we can take a look.

If I remember rightly the fixes for this went into the scsi tree a couple
of months ago. The patch is in the -mm tree as well. No idea why its
gotten stuck as an obvious one liner.

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

Re: Top kernel oopses/warnings this week

2007-12-17 Thread Stefan Richter

Jon Masters wrote:
 On Sun, 2007-12-16 at 21:51 -0500, Dave Jones wrote:
 On Sat, Dec 15, 2007 at 04:49:05PM +0100, Stefan Richter wrote:
  
   Reports about tainted kernels have arguably less value.  It would be
   good to hide such reports until a report of the same oops in an
   untainted kernel was found.
  
 I disagree with this.  It's useful to have a we've seen this before,
 and every time, it was tainted with xyz module datapoint, especially
 if no untainted copies of that oops turn up.
 
 +1
 
 In fact, that's even more useful in many cases, if it helps demonstrate
 that the oops is associated with a particular buggy binary driver. I can
 see a lot of potentially interesting statistics coming from that too.

-1  :-)

I don't care at all what this xyz module does or does not do by and in
itself.

(Of course since at least two people care and since this makes life
easier for Arjan, just keep listing reports about tainted kernels like
you do now.  It just so happens that different people are interested in
different things.)
-- 
Stefan Richter
-=-=-=== ==-- =---=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-17 Thread Tetsuo Handa

Hello.

Al Boldi wrote:
 I think the answer is obvious:  Tetsuo wants to add functionality that the
 MACs are missing.  So, instead of adding this functionality per MAC, he
 proposes to add it as ground work, to be combined with any MAC.
Yes, that's right.

This filesystem is designed to be used with TOMOYO Linux,
but this filesystem can be used with other MAC implementations too.

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

swapping in 2.6.24-rc5-git3

2007-12-17 Thread Lukas Hejtmanek

Hello,

does /proc/sys/vm/swappiness still work as expected? 
# /proc/sys/vm# cat swappiness 
0

but scp-ing 2GB file causes many processes are swapped out due to increase of
the file cache size. Why? This is totally catastrophic behaviour on the desktop.

Is there a way to avoid it except turning off the swap?

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.


On 17-12-07 14:09, Ingo Molnar wrote:


-#ifndef CONFIG_UDELAY_IO_DELAY
-static int __init dmi_alternate_io_delay_port(const struct dmi_system_id *id)
+static int __init dmi_io_delay_0xed_port(const struct dmi_system_id *id)
 {
-   printk(KERN_NOTICE %s: using alternate I/O delay port\n, id-ident);
-   io_delay = alternate_io_delay;
+   printk(KERN_NOTICE %s: using 0xed I/O delay port\n, id-ident);
+   io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
+
return 0;
 }
This isn't correct. DMI shouldn't override the CONFIG choice or 
someone with matching DMI will have a defective CONFIG option. That's 
why I put all of it inside #ifndef.


no, the DMI quirk is just that: a quirk that makes boxes work. The DMI 
quirk takes precedence over just about any .config default, except an 
explicit boot-commandline override.


No, most definitely not. Having the user select udelay or none through the 
kernel config and then the kernel deciding ah, you know what, I'll know 
better and use port access anyway is _utterly_ broken behaviour. Software 
needs to listen to its master.


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/

Re: [PATCH] i386: hard_{en,dis}able_TSC can be static


thanks, applied your patch to x86.git - queued it up for v2.6.25.

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

Re: [PATCH] x86-64: make pda's cpunumber and nodenumber unsigned


* Jan Beulich [EMAIL PROTECTED] wrote:

 This generally allows better code to be generated, since the zero- 
 extension during 32-bit operations comes for free (needed when the 
 result is used as array index or similar), whereas sign extension must 
 be done explicitly and frequently requires a one byte larger 
 instruction due to the necessary rex64 prefix.

good catch! Applied your patch to x86.git - queued it up for v2.6.25. I 
bet there are tons of other instances where we use signed instead of 
unsigned and get worse code generation.

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

Re: [PATCH] x86-64: honor notify_die() returning NOTIFY_STOP


* Jan Beulich [EMAIL PROTECTED] wrote:

 This requires making die() return a value, making its callers honor 
 this (and be prepared that it may return), and making oops_end() have 
 two additional parameters.

thanks, applied your patch to x86.git - queued it up for v2.6.25.

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

RE: [patch 1/5] x86, ptrace: remove bad comment

2007-12-17 Thread Metzger, Markus T

-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED] 
Sent: Samstag, 15. Dezember 2007 08:30

another detail: shouldnt this be structured so that the APIs are 
introduced in kernel/ptrace.c, and that the architecture offers the 
mechanism. (which would thus be ptrace-independent) This would 
also open 
these APIs up to kernel-internal use and to be used by other 
architectures.

Isn't this best done once we actually have at least one other
architecture?

The DS interface should be fine for kernel and user trace on x86, but it
may not be the best interface for other architectures.

regards,
markus.
-
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: Tesing of / bugs in new timerfd API

2007-12-17 Thread Michael Kerrisk

Hi Davide,

On 12/16/07, Davide Libenzi [EMAIL PROTECTED] wrote:
 On Fri, 14 Dec 2007, Michael Kerrisk wrote:

  You snipped my example that demonstrated the problem.  Both of the
  following runs create a timer that expires 10 seconds from now, but
  observe the difference in the value returned by timerfd_gettime():
 
  $ ./timerfd_test 10 # does not use TFD_TIMER_ABSTIME
  Initial setting for settime:   value=10.000, interval=0.000
  ./timerfd_test g
  (elapsed time=  1)
  Current value: value=346.448, interval=0.000
 
  $ ./timerfd_test -a 10  # uses TFD_TIMER_ABSTIME
  Initial setting for settime:   value=1197630855.254, interval=0.000
  ./timerfd_test g
  (elapsed time=  1)
  Current value: value=1197630855.254, interval=0.000
 
  Either there's an inconsistency here depending on the use of
  TFD_TIMER_ABSTIME, or there is a bug in my understanding or my test
 program
  (but so far I haven't spotted that bug ;-).).

 Can you try the two patches below? I tried them on my 32 bit box (one of
 the rare beasts still lingering around here) and it seems to be working
 fine (those go on top of the previous ones).

Against 2.6.24-rc5, I applied first your earlier patches (v3) and
then the newest patch.  My tests confirm that:

 This fixed the 32 bit tick-count truncation, and makes the time returned
 to be the remaining time till the next expiration.

Are you going to resubmit a new patch set that includes these latest changes?

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/

Re: [PATCH] x86: fix ref-counting bug in change_page_attr()


* Jan Beulich [EMAIL PROTECTED] wrote:

 When either calling change_page_attr() with the default attributes 
 pages in the direct mapping have and a page's attributes already were 
 set to the default or when changing the attributes from one 
 non-default value to another, the reference counting broke, leading to 
 either premature restoration of a large page or missing the 
 opportunity to do so.
 
 At the same time, make __PHYSICAL_MASK_SHIFT on 64-bits the value it 
 architecturally ought to have.

hm, does this patch fix any real bug seen live? (if yes then do you have 
links to it, etc?) It would be a v2.6.24 fix in theory but it looks too 
dangerous for that. So i've queued it up for v2.6.25, for the time 
being.

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Pavel Machek

On Mon 2007-12-17 14:22:26, Rene Herman wrote:
 On 17-12-07 14:09, Ingo Molnar wrote:

 -#ifndef CONFIG_UDELAY_IO_DELAY
 -static int __init dmi_alternate_io_delay_port(const struct 
 dmi_system_id *id)
 +static int __init dmi_io_delay_0xed_port(const struct dmi_system_id 
 *id)
  {
 -  printk(KERN_NOTICE %s: using alternate I/O delay port\n, id-ident);
 -  io_delay = alternate_io_delay;
 +  printk(KERN_NOTICE %s: using 0xed I/O delay port\n, id-ident);
 +  io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
 +
return 0;
  }
 This isn't correct. DMI shouldn't override the CONFIG choice or someone 
 with matching DMI will have a defective CONFIG option. That's why I put 
 all of it inside #ifndef.
 no, the DMI quirk is just that: a quirk that makes boxes work. The DMI 
 quirk takes precedence over just about any .config default, except an 
 explicit boot-commandline override.

 No, most definitely not. Having the user select udelay or none through the 
 kernel config and then the kernel deciding ah, you know what, I'll know 
 better and use port access anyway is _utterly_ broken behaviour. Software 
 needs to listen to its master.

That's what command line is for. Ingo is right here.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-17 Thread Tetsuo Handa

( This is a reply to http://lkml.org/lkml/2007/12/17/27 .)

Hello.

David Wagner wrote:
 But the point is that it's not enough just to prevent attackers
 from mounting other filesystems over this filesystem.  I can think
 of all sorts of ways that an admin-level attacker might be able to
 prevent other administrators from logging in.  If your defense strategy
 involves trying to enumerate all of those possible ways and then shut
 them down one by one, you're relying upon a defense strategy known as
 blacklisting.  Blacklisting has a terrible track record in the
 security field, because it's too easy to overlook one pathway.
Of course, I assume whitelisting.
SELinux and TOMOYO Linux and many other MAC implementations uses
whitelisting approach, and this filesystem is whiltelisting approach.

This filesystem handles what MAC implementations don't handle.
In other words, it is a remaining hole.

I'm proposing:

 Don't you think it is dangerous to assume files in /dev directory
 have appropriate filename and attributes binding?
 MAC can restrict processes who can create files in /dev directory,
 but MAC doesn't enforce filename and attributes binding.
 So, how about enforcing filename and attributes binding in filesystem layer?

Regards.

To David Wagner:
  Could you please Cc: me so that I can reply to your message?
  I can't reply to your message since I'm reading this ml in daily digest mode.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.


On 17-12-07 14:31, Pavel Machek wrote:


On Mon 2007-12-17 14:22:26, Rene Herman wrote:

On 17-12-07 14:09, Ingo Molnar wrote:


-#ifndef CONFIG_UDELAY_IO_DELAY
-static int __init dmi_alternate_io_delay_port(const struct 
dmi_system_id *id)
+static int __init dmi_io_delay_0xed_port(const struct dmi_system_id 
*id)

 {
-   printk(KERN_NOTICE %s: using alternate I/O delay port\n, id-ident);
-   io_delay = alternate_io_delay;
+   printk(KERN_NOTICE %s: using 0xed I/O delay port\n, id-ident);
+   io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
+
return 0;
 }
This isn't correct. DMI shouldn't override the CONFIG choice or someone 
with matching DMI will have a defective CONFIG option. That's why I put 
all of it inside #ifndef.
no, the DMI quirk is just that: a quirk that makes boxes work. The DMI 
quirk takes precedence over just about any .config default, except an 
explicit boot-commandline override.
No, most definitely not. Having the user select udelay or none through the 
kernel config and then the kernel deciding ah, you know what, I'll know 
better and use port access anyway is _utterly_ broken behaviour. Software 
needs to listen to its master.


That's what command line is for. Ingo is right here.


No. The kernel shouldn't provide defective config options.

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/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread David P. Reed


Rene Herman wrote:
No, most definitely not. Having the user select udelay or none through 
the kernel config and then the kernel deciding ah, you know what, 
I'll know better and use port access anyway is _utterly_ broken 
behaviour. Software needs to listen to its master.


When acting as an ordinary user, the .config is beyond my control 
(except on Gentoo).   It is in control of the distro (Fedora, Ubuntu, 
... but perhaps not Gentoo).  I think the distro guys want a default 
behavior that is set in .config, with quirk overrides being done when 
needed.   And of course the user in his/her boot params gets the final say.

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

Re: [PATCH] x86: move interrupts[] to .rodata/.init.data


* Jan Beulich [EMAIL PROTECTED] wrote:

 The array is never written, and on 64-bits it's not even being used
 past initial boot.

thanks - applied your patch to x86.git, queued up for v2.6.25.

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

Re: [PATCH] x86: make __{save,restore}_processor_state static


* Jan Beulich [EMAIL PROTECTED] wrote:

 .. allowing to remove their declarations from a global include file 
 (the symbols don't exist for anything but x86).
 
 Likewise for 64-bits' fix_processor_context(), just that that one was 
 properly declared in an arch-specific header.

thanks, applied your patch to x86.git, for v2.6.25.

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread David P. Reed


About to start building and testing.  It will take a few hours.

Ingo Molnar wrote:
here's an updated rollup patch, against 2.6.24-rc4. David, could you 
please try this? This should work out of box on your system, without any 
boot option or other tweak needed.



  

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

Re: [PATCH] x86-64: make pda's cpunumber and nodenumber unsigned

2007-12-17 Thread Jan Beulich

 Ingo Molnar [EMAIL PROTECTED] 17.12.07 14:26 

* Jan Beulich [EMAIL PROTECTED] wrote:

 This generally allows better code to be generated, since the zero- 
 extension during 32-bit operations comes for free (needed when the 
 result is used as array index or similar), whereas sign extension must 
 be done explicitly and frequently requires a one byte larger 
 instruction due to the necessary rex64 prefix.

good catch! Applied your patch to x86.git - queued it up for v2.6.25. I 
bet there are tons of other instances where we use signed instead of 
unsigned and get worse code generation.

Yes, definitely. This patch was kind of a testing one whether this is a
welcome change. As it appears to be, I'll probably produce more as I
run into respective cases.

Jan

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

Re: [PATCH] x86: adjust enable_NMI_through_LVT0()


* Jan Beulich [EMAIL PROTECTED] wrote:

 Its previous use in a call to on_each_cpu() was pointless, as at the 
 time that code gets executed only one CPU is online. Further, the 
 function can be __cpuinit, and for this to work without 
 CONFIG_HOTPLUG_CPU setup_nmi() must also get an attribute (this one 
 can even be __init; on 64-bits check_timer() also was lacking that 
 attribute).

thanks, applied.

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

Re: 2.6.23.8: OOM killer kills wrong jobs

2007-12-17 Thread Alan Cox

 ...but I've run into a situation in which a system on which I *have* set
 no overcommit is being blasted by the OOM killer anyway.

Looks like the kernel is eating all the resources needed.

Linux babyalcor 2.6.23.1 #1 SMP Fri Oct 26 15:35:18 EDT 2007 \
 i686 Dual Core AMD Opteron(tm) Processor 280 AuthenticAMD GNU/Linux

32bit kernel, 16GB of RAM. 

No suprise I'm afraid. Handling 16GB on a 32bit kernel, which has to
manage it all through a small addressible memory window is right on the
limit of what the standard kernel will handle (8GB is probably as high as
I would go). The no overcommit code ensures that user space doesn't
overcommit, but the kernel can get itself short of low memory resources
on a big box with 32bit kernels very easily. (In 64bit mode the CPU can
address all the memory directly so the problem vanishes).

You will *probably* get stable 16GB with the vendor tuned enterprise
kernels (RHEL, CentOS etc), or run a 64bit kernel and then the kernel
isn't trying the software equivalent of managing a filing cabinet through
the keyhole.

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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.


On 17-12-07 14:32, David P. Reed wrote:


Rene Herman wrote:
No, most definitely not. Having the user select udelay or none through 
the kernel config and then the kernel deciding ah, you know what, 
I'll know better and use port access anyway is _utterly_ broken 
behaviour. Software needs to listen to its master.


When acting as an ordinary user, the .config is beyond my control 
(except on Gentoo).   It is in control of the distro (Fedora, Ubuntu, 
... but perhaps not Gentoo).  I think the distro guys want a default 
behavior that is set in .config, with quirk overrides being done when 
needed.   And of course the user in his/her boot params gets the final say.


Yes, and when the user/distributor specifically selected udelay or none as 
an I/O delay method it makes no sense whatsoever to have the kernel override 
that again -- the DMI hack only fixes something for the default case, when 
_no_ specific choice had been made (which the current setup can't express 
but mine did).


I feel particularly strongly (always) about that listen to its master bit. 
The kernel does not know better then whomever configured it, even when it does.


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/

Re: [PATCH] x86: fix ref-counting bug in change_page_attr()

2007-12-17 Thread Jan Beulich

 Ingo Molnar [EMAIL PROTECTED] 17.12.07 14:28 

* Jan Beulich [EMAIL PROTECTED] wrote:

 When either calling change_page_attr() with the default attributes 
 pages in the direct mapping have and a page's attributes already were 
 set to the default or when changing the attributes from one 
 non-default value to another, the reference counting broke, leading to 
 either premature restoration of a large page or missing the 
 opportunity to do so.
 
 At the same time, make __PHYSICAL_MASK_SHIFT on 64-bits the value it 
 architecturally ought to have.

hm, does this patch fix any real bug seen live? (if yes then do you have 
links to it, etc?) It would be a v2.6.24 fix in theory but it looks too 
dangerous for that. So i've queued it up for v2.6.25, for the time 
being.

I had run into the issue with experimental code of mine quite a while back
(i.e. I don't even recall what exactly I was doing back then). After that I
just continued to keep the fix (which I had submitted before, but which
collided with something in Andi's tree back then iirc).

Jan

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

Re: [PATCH] x86-64: also define AT_VECTOR_SIZE_ARCH


* Jan Beulich [EMAIL PROTECTED] wrote:

 The patch introducing this left out x86-64, despite it also having 
 extra entries.

thanks, applied. Is there any 2.6.24 urgency for this?

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

Re: 2.6.24-rc5-mm1 compile failure: usbhid_lookup_quirk

2007-12-17 Thread Jiri Kosina

On Mon, 17 Dec 2007, Andrew Morton wrote:

MODPOST 196 modules
ERROR: usbhid_lookup_quirk [drivers/hid/usbhid/usbmouse.ko]
undefined!
ERROR: usbhid_lookup_quirk [drivers/hid/usbhid/usbkbd.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
  The problem was fixed by defining CONFIG_USB_HID=m - but I think that
  should happen automatically if it is necessary.
  .config was created by running make oldconfig against 2.6.23-rc8-mm2:
 Thanks.  That's coming out of git-hid.patch.

Thanks a lot for the report, I will fix that up in my tree.

By the way, please be aware that you almost certainly _do not_ want to use 
usbmouse and usbkbd drivers. Please read their Kconfig help text.

-- 
Jiri Kosina
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Early boot debugging via FireWire (ohci1394_dma=early)


* Bernhard Kaindl [EMAIL PROTECTED] wrote:

 Subject of this patch:
 
 This patch adds a new configuration option, which adds support for a 
 new early_param which gets checked in 
 arch/x86/kernel/setup_{32,64}.c:setup_arch() to decide wether 
 OHCI-1394 FireWire controllers should be initialized and enabled for 
 physical DMA access to allow remote debugging of early problems like 
 issues ACPI or other subsystems which are executed very early.
 
 If the config option is not enabled, no code is changed, and if the 
 boot paramenter is not given, no new code is executed, and independent 
 of that, all new code is freed after boot, so the config option can be 
 even enabled in standard, non-debug kernels.
 
 With specialized tools, it is then possible to get debugging 
 information from machines which have no serial ports (notebooks) such 
 as the printk buffer contents, or any data which can be referenced 
 from global pointers, if it is stored below the 4GB limit and even 
 memory dumps of of the physical RAM region below the 4GB limit can be 
 taken without any cooperation from the CPU of the host, so the machine 
 can be crashed early, it does not matter.

cool stuff! I've tentatively added your patch to x86.git (pending more 
review feedback from others), but it already looks quite nice to me.

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

Re: [PATCH] x86-64: also define AT_VECTOR_SIZE_ARCH

2007-12-17 Thread Jan Beulich

 Ingo Molnar [EMAIL PROTECTED] 17.12.07 14:42 

* Jan Beulich [EMAIL PROTECTED] wrote:

 The patch introducing this left out x86-64, despite it also having 
 extra entries.

thanks, applied. Is there any 2.6.24 urgency for this?

While I haven't seen x86-64 to break due to this (it appears that 32-bit
apps would be more susceptible), I know that we had major problems
with the respective piece missing from the 32-bit Xen kernels in openSuSE
10.3, so I would strongly suggest putting this into .24.

Jan

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

Re: [PATCH] x86-64: also define AT_VECTOR_SIZE_ARCH