Re: Fix soft lockup with iSeries viocd driver
On Wed, Feb 28 2007, Tony Breeds wrote: On Tue, Feb 27, 2007 at 03:33:34PM +0100, Jens Axboe wrote: It looks ok (better than end_request()), though it would still be nice to properly end requests. See the recent thread on the lguest block driver. Hi Jens, I read through the lguest thread and came up with the patch below, I hope I understood correctly. We still need to do the check to make sure we ask for at least one sector to be processed in end_that_request_first(), as the request that triggers the lockup here (an sg_io ioctl in this case), has both req-hard_nr_sectors and req-hard_cur_sectors = 0. Yep that looks better. From: Tony Breeds [EMAIL PROTECTED] Fix soft lockup with iSeries viocd driver, caused by eventually calling end_that_request_first() with nr_bytes 0. The lockup is triggered by hald, interrogating the device. Signed-off-by: Tony Breeds [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Removing request from I/O scheduler queue
On Tue, Feb 27 2007, Swetha Krishnan wrote: I'm using linux 2.6.12 within user-mode linux. I need to remove a specific I/O request (that I have means to identify) from the I/O scheduler queues instead of moving it to the driver dispatch queue. To remove a request from the anticipatory scheduler's sort/fifo queues , I'm making a call to as_remove_queued_request(), from within as_move_to_dispatch(). Before removing it, I invoke the as_find_next_arq() function so that the scheduler can pick the next request once this one is removed. Everything works fine as far as the remove is concerned, but after returning from the remove function and the end_io function that I call on the request's bio field(a dummy end_io), the scheduler fails to proceed with the next request chosen. I do check that if the next req chosen is NULL, I exit from the as_move_to_dispatch() function but even if I do this, the kernel panics after exiting from that function. The chief points of panic from the (larger) dump, seems to be a02277d0: [a005eec3] handle_IRQ_event+0x37/0x8c a0227800: [a005efaf] __do_IRQ+0x97/0xe0 a0227820: [a000defc] do_IRQ+0x30/0x3c Could you give me any pointers as to why this is happening? Is there any additional cleanup that I need to do when I remove a request from the scheduler's queues that as_remove_queued_request() does not already do? I am rather new to linux I/O scheduling, so would be great if you could let me know if there something basic I'm missing here. You need to show your code, nobody can help you with such a vague description of what is going on. Either you are illegally removing a request, or your removal code is buggy. That is about all that one can conclude from the above. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
On 02/28/2007 02:04 PM, Alan wrote: PLIP/Laplink runs bidirectional on ordinary parallel ports. The bidirectional part of parallel ports in normal modes is still used for things like PnP detection of printer and drivers. And my parallel port Iomega ZIP drive, it seems. I actually checked earlier and although it doesn't use DMA (it says it's using EPP 32-bit) it does use bidrectional communication; it's an sd device. I admit most of those will be confined to history as well with respect to actual use (they existed with 100MB, 250 and 750MB disks, although the 750 one probably not as parallel) but they looked cool, so people haven't just thrown them away yet :) 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 00/21] 2.6.19-stable review
Zwane Mwaikambo [EMAIL PROTECTED] writes: Hi Eric, Thanks for getting this cruft cleaned up. I have a few comments regarding; handle-irqs-pending-in-irr-during-irq-migration.patch 1) It relies on checking the IRR, this could race with the corresponding vector bit being set by hardware. The mostly correct assumption is that because that vector is masked and has been for a while we should not have a race. 2) apic_handle_pending_vector is oddly named since it doesn't actually handle a pending vector but drops it if it has been freed. 3) It looks complex So how about the following scheme. Add a check in do_IRQ whether the irq's domain contains the current cpu, if not we free the vector upon handler completion. Because that check will leak vector entries. And after a while the box will be unable to migrate irqs, and possible something more severe. Yes. It is moderately complex. After receiving a little feedback like this I have something much simpler and more robust mered into the current git for 2.6.21. Which except for my stupid it doesn't compile on uniprocessor bug should be good. However it took me 13 patches to come up with something clean and simple. Basically I wait until an irq has arrived at the new location until I free it, and even then I send a lowest priority IPI to land to the cpu in question before I free it so that if that other cpu has it stuck in the pending bit that gets processed before the freeing happens. Even with that I'm still only 99% certain that the last in flight irq before we reprogrammed it actually made it to a different cpus local apic. But there appears to be nothing more that I can do. I have exhausted every property I can find. Added to that is the fact that simply handing the irq in IRR empirically is sufficient. So I truly believe in practice the code in my first patch is sufficient, and what I am doing for 2.6.21 is better simply because it is simpler and much more paranoid and thus affords us with a bit of margin. If one irq is delivered to a local apic you would expect the previous incarnation of that irq to be delivered to a local apic first... Honestly I would be completely happy if all that gets back ported is my stupid patch, that adds: if (!disable_apic) ack_APIC_irq(); Before if (printk_ratelimit()) printk(KERN_EMERG %s: %d.%d No irq handler for vector\n, In do_IRQ. That is sufficient in most cases to keep the box from falling over. Is obviously correct. And only emits a scary message. If that isn't sufficient to give everyone warm fuzzy. I think the patch under discussion make sense for a backport. At least it doesn't change lot so things. Honestly. I am happy if I fix this for 2.6.21. Beyond that I am happy to offer my advice but I have no expectations of anyone following it. Possibly I suffer from giving to complete an answer? What are the rules that are supposed to govern backports to stable trees these days anyway? Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: lanana: Add major/minor entries for PPC QE UART devices
--- devices-2.6+.txt 2007-02-22 13:37:18.0 -0600 +++ devices-2.6+.new 2007-02-22 13:42:50.0 -0600 @@ -2770,7 +2770,10 @@ 45 = /dev/ttyMM1 Marvell MPSC - port 1 46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0 ... - 47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 + 49 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 + 46 = /dev/ttyQE0 PPC QE (UCC) - port 0 + ... + 49 = /dev/ttyQE3 PPC QE (UCC) - port 3 50 = /dev/ttyIOC0 Altix serial card ... 81 = /dev/ttyIOC31 Altix serial card Got around looking at this one. I'm fine with this approach, but the CPM5 fix looks wrong. Shouldn't it be: 49 = /dev/ttyCPM3 PPC CPM (SCC or SMC) - port 3 instead? Thx, Torben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20 SATA error
hello, Can someone tell me what this means? ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/100 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] vlan net drivers: avoid a 4-order allocation
Hello,
This patch splits the vlan_group struct into a multi-allocated struct. On
x86_64, the size of the original struct is a little more than 32KB, causing
a 4-order allocation, which is prune to problems caused by buddy-system
external fragmentation conditions.
I couldn't just use vmalloc() because vfree() cannot be called in the
softirq context of the RCU callback.
Signed-off-by: Dan Aloni [EMAIL PROTECTED]
---
commit 3e6b63d0827461154066ff4c51f295bfd5006bd7
tree ccd06cfd2acd6e8f2d07dd2fa2f5cf31dc0c1011
parent 8d1117a9f5d302d8d460fbe7ef322b382e45c9ce
author Dan Aloni [EMAIL PROTECTED] Wed, 28 Feb 2007 14:20:36 +0200
committer Dan Aloni [EMAIL PROTECTED] Wed, 28 Feb 2007 14:20:36 +0200
drivers/net/8139cp.c|3 +--
drivers/net/acenic.c|5 +
drivers/net/amd8111e.c |3 +--
drivers/net/bnx2.c |4 +---
drivers/net/bonding/bond_main.c | 14 +++--
drivers/net/chelsio/cxgb2.c |3 +--
drivers/net/e1000/e1000_main.c | 13 +---
drivers/net/ehea/ehea_main.c|3 +--
drivers/net/gianfar.c |3 +--
drivers/net/ixgb/ixgb_main.c|5 ++---
drivers/net/ns83820.c |3 +--
drivers/net/r8169.c |3 +--
drivers/net/s2io.c |3 +--
drivers/net/sky2.c |3 +--
drivers/net/starfire.c |5 ++---
drivers/net/tg3.c |3 +--
drivers/net/typhoon.c |3 +--
drivers/s390/net/qeth_main.c| 25 ---
include/linux/if_vlan.h | 25 ---
net/8021q/vlan.c| 42 ++-
20 files changed, 96 insertions(+), 75 deletions(-)
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index 6f93a76..12c8453 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -448,8 +448,7 @@ static void cp_vlan_rx_kill_vid(struct net_device *dev,
unsigned short vid)
spin_lock_irqsave(cp-lock, flags);
cp-cpcmd = ~RxVlanOn;
cpw16(CpCmd, cp-cpcmd);
- if (cp-vlgrp)
- cp-vlgrp-vlan_devices[vid] = NULL;
+ vlan_group_set_device(cp-vlgrp, vid, NULL);
spin_unlock_irqrestore(cp-lock, flags);
}
#endif /* CP_VLAN_TAG_USED */
diff --git a/drivers/net/acenic.c b/drivers/net/acenic.c
index 33c6645..7138e0e 100644
--- a/drivers/net/acenic.c
+++ b/drivers/net/acenic.c
@@ -2293,10 +2293,7 @@ static void ace_vlan_rx_kill_vid(struct net_device *dev,
unsigned short vid)
local_irq_save(flags);
ace_mask_irq(dev);
-
- if (ap-vlgrp)
- ap-vlgrp-vlan_devices[vid] = NULL;
-
+ vlan_group_set_device(ap-vlgrp, vid, NULL);
ace_unmask_irq(dev);
local_irq_restore(flags);
}
diff --git a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c
index 18896f2..8d57f5a 100644
--- a/drivers/net/amd8111e.c
+++ b/drivers/net/amd8111e.c
@@ -1738,8 +1738,7 @@ static void amd8111e_vlan_rx_kill_vid(struct net_device
*dev, unsigned short vid
{
struct amd8111e_priv *lp = netdev_priv(dev);
spin_lock_irq(lp-lock);
- if (lp-vlgrp)
- lp-vlgrp-vlan_devices[vid] = NULL;
+ vlan_group_set_device(lp-vlgrp, vid, NULL);
spin_unlock_irq(lp-lock);
}
#endif
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index ee7b75b..7f5f772 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -4470,9 +4470,7 @@ bnx2_vlan_rx_kill_vid(struct net_device *dev, uint16_t
vid)
struct bnx2 *bp = netdev_priv(dev);
bnx2_netif_stop(bp);
-
- if (bp-vlgrp)
- bp-vlgrp-vlan_devices[vid] = NULL;
+ vlan_group_set_device(bp-vlgrp, vid, NULL);
bnx2_set_rx_mode(dev);
bnx2_netif_start(bp);
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 6482aed..55d3553 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -489,9 +489,9 @@ static void bond_vlan_rx_kill_vid(struct net_device
*bond_dev, uint16_t vid)
/* Save and then restore vlan_dev in the grp array,
* since the slave's driver might clear it.
*/
- vlan_dev = bond-vlgrp-vlan_devices[vid];
+ vlan_dev = vlan_group_get_device(bond-vlgrp, vid);
slave_dev-vlan_rx_kill_vid(slave_dev, vid);
- bond-vlgrp-vlan_devices[vid] = vlan_dev;
+ vlan_group_set_device(bond-vlgrp, vid, vlan_dev);
}
}
@@ -551,9 +551,9 @@ static void bond_del_vlans_from_slave(struct bonding *bond,
struct net_device *s
/* Save and then restore vlan_dev in the grp array,
* since the slave's driver might clear it.
*/
- vlan_dev = bond-vlgrp-vlan_devices[vlan-vlan_id];
+ vlan_dev = vlan_group_get_device(bond-vlgrp,
[PATCH] acpi: fan after suspend-to-mem fix
acpi_fan_suspend should probably set state to ACPI_D3, rather than ACPI_D0. With this change the fan works after S3 suspend atleast on HP nw8000 laptop, for which the suspended fan has been broken since sword-and-stone. Signed-off-by: Tommi Kyntola [EMAIL PROTECTED] --- Why this was ACPI_D0 beats me, but it's been that way since the _suspend/_resume functios got added in the commit 0feabb01d93e5801d1127416a66cfc3963280bca (2.6.18-rc1, I think). The fan hasn't worked on my HP nw8000 laptop after an S3 suspend ever, but fixing that to ACPI_D3 there finally makes it work as expected. If there was some hidden reason why that was set to ACPI_D0, then perhaps a config option for some ICH4 or HP laptops is called for. Kynde diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c index 045c894..7ae70b0 100644 --- a/drivers/acpi/fan.c +++ b/drivers/acpi/fan.c @@ -243,7 +243,7 @@ static int acpi_fan_suspend(struct acpi_device *device, int state) if (!device) return -EINVAL; - acpi_bus_set_power(device-handle, ACPI_STATE_D0); + acpi_bus_set_power(device-handle, ACPI_STATE_D3); return AE_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: lanana: Add major/minor entries for PPC QE UART devices
Mathiasen, Torben wrote: Got around looking at this one. I'm fine with this approach, but the CPM5 fix looks wrong. Shouldn't it be: 49 = /dev/ttyCPM3 PPC CPM (SCC or SMC) - port 3 instead? Well, how many CPM devices can exist? If there are really 6 ports possible, they need minors up to 51. Also, if QE really is just CPM v3, and they share the same minors, why change the name? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-mm2: Oops in generic_make_request not git-block.patches fault
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I rebuild the kernel, without the git-block patches Patches revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch git-block.patch git-block-fixup.patch git-block-dupe-definitions.patch git-block-xfs-barriers-broke.patch but i still get: BUG: unable to handle kernel NULL pointer dereference at virtual address 000 4 printing eip: c01f369b *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:1d.3/usb5/5-0:1.0/bInterfaceProtoco l Modules linked in: fglrx(P) arc4 ecb blkcipher cryptomgr crypto_algapi ieee80211 _crypt_wep ipw2200 ieee80211 ieee80211_crypt sk98lin intel_agp agpgart CPU:0 EIP:0060:[c01f369b]Tainted: P VLI EFLAGS: 00210297 (2.6.20-tEwaN1 #4) EIP is at __make_request+0xeb/0x2d7 eax: ebx: ecx: edx: 00010585 esi: dff497d4 edi: c1974d54 ebp: c1947200 esp: ec6b1b1c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process firefox-bin (pid: 10937, ti=ec6b task=c1938540 task.ti=ec6b) Stack: c1947200 dff4c494 0008 0100 c1947200 dff497d4 c01f1778 ef4c15c0 00672810 ef07c9a0 0008 ef7de6b8 c1948d8c 00200202 c192dc00 000112d0 00200202 c017c700 0001 c1947200 Call Trace: [c01f1778] generic_make_request+0x18d/0x1bb [c017c700] do_mpage_readpage+0x44e/0x454 [c01f343e] submit_bio+0xc3/0xca [c0192124] ext3_get_block+0xa8/0xbe [c017c75b] mpage_end_io_read+0x0/0x61 [c017bd81] mpage_bio_submit+0x19/0x1d [c017c5fe] do_mpage_readpage+0x34c/0x454 [c0179168] bio_add_page+0x31/0x37 [c019207c] ext3_get_block+0x0/0xbe [c013e2b9] add_to_page_cache+0x37/0xa7 [c017c8d1] mpage_readpages+0xb2/0x119 [c019207c] ext3_get_block+0x0/0xbe [c02781d4] ata_qc_issue_prot+0xfe/0x234 [c0275255] ata_qc_issue+0x43b/0x48d [c02795ca] ata_scsi_rw_xlat+0x126/0x19c [c01915f4] ext3_readpages+0x0/0x15 [c0144143] __do_page_cache_readahead+0x16a/0x237 [c019207c] ext3_get_block+0x0/0xbe [c026bce9] scsi_prep_fn+0x1b5/0x227 [c01fbdfb] radix_tree_scan_hole_backward+0x17/0x2d [c0144799] try_context_based_readahead+0x307/0x336 [c0102dbc] __switch_to+0x161/0x17b [c01442c9] ra_submit+0xb9/0xc5 [c0144a9b] page_cache_readahead_adaptive+0x2d3/0x4a4 [c036552a] io_schedule+0x4e/0x57 [c013e066] file_read_actor+0x79/0xca [c013e7f8] do_generic_mapping_read+0x1a4/0x4f3 [c01409ad] generic_file_aio_read+0x1af/0x1f6 [c013dfed] file_read_actor+0x0/0xca [c01efb84] elv_next_request+0x105/0x114 [c015af8f] do_sync_read+0xc7/0x10a [c026b50c] scsi_next_command+0x25/0x2f [c0128560] wake_bit_function+0x0/0x44 [c015defe] sys_fstat64+0x1e/0x23 [c015aec8] do_sync_read+0x0/0x10a [c015b6f2] vfs_read+0x88/0x10a [c015ba3a] sys_read+0x41/0x67 [c0103cce] sysenter_past_esp+0x5f/0x85 [c036] inet6_synq_hash+0xe0/0xf5 === Code: 83 f8 02 75 0d 89 e9 89 da 89 f0 e8 82 ec ff ff eb 0e 48 75 13 89 e9 89 da 89 f0 e8 f0 e9 ff ff 85 c0 0f 85 e5 01 00 00 8b 5b 04 8b 43 04 0f 18 00 90 8d 47 14 39 c3 75 be fa 89 e0 25 00 e0 ff EIP: [c01f369b] __make_request+0xeb/0x2d7 SS:ESP 0068:ec6b1b1c Ths time i had to wait a few hours till the Bug jumped on. I am trying to make a bisection search, without the patches, but i am not that experienced. HTH Oli - -- This email is intended for the person specified at the beginning of this message. It is confidential and may contain legally privileged information. If you have received this in error please let us know. You should note that you may not copy this email or use any information contained within it. Messages sent by email over the Internet are not necessarily completely secure. We accept no responsibility for changes made to this email after we sent it. You should be aware of these risks if you communicate with us by email. If you are unsure about how to act on this email please contact the person sending it to you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5XxnTvJ2Ft8Rz5cRAlVlAJ9jWSrE1Jf6KS476LNgHBr5nUjGOgCcDR34 SNFSeDQx6IhF4I1HWe25N1c= =00jf -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc2
Brice Goglin [EMAIL PROTECTED] writes: Linus Torvalds wrote: Oh well.. I'm not very proud of this, because quite frankly, -rc2 has way more changes than I really like. Hi Linus, rc2 fails to build on my thinkpad t43: CC arch/i386/kernel/io_apic.o arch/i386/kernel/io_apic.c: In function 'setup_IO_APIC_irqs': arch/i386/kernel/io_apic.c:1357: error: 'struct irq_desc' has no member named 'affinity' arch/i386/kernel/io_apic.c: In function 'io_apic_set_pci_routing': arch/i386/kernel/io_apic.c:2878: error: 'struct irq_desc' has no member named 'affinity' make[1]: *** [arch/i386/kernel/io_apic.o] Error 1 make: *** [arch/i386/kernel] Error 2 The problem is caused by affinity being within #ifdef SMP in struct irq_desc in irq.h: #ifdef CONFIG_SMP cpumask_t affinity; unsigned intcpu; #endif I don't know whether the whole functions or just a single line should be placed under #ifdef CONFIG_SMP. Eric (in CC) will know better than I do. Yes. I goofed, and missed that stupid case. The offending lines should just die. Patch already sent to Linus. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-mm2: Oops in generic_make_request not git-block.patch's fault
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I rebuild the kernel, without the git-block patches Mr. Piotrowski wrote: revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch git-block.patch git-block-fixup.patch git-block-dupe-definitions.patch git-block-xfs-barriers-broke.patch but i still get: BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c01f369b *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:1d.3/usb5/5-0:1.0/bInterfaceProtoco l Modules linked in: fglrx(P) arc4 ecb blkcipher cryptomgr crypto_algapi ieee80211 _crypt_wep ipw2200 ieee80211 ieee80211_crypt sk98lin intel_agp agpgart CPU:0 EIP:0060:[c01f369b]Tainted: P VLI EFLAGS: 00210297 (2.6.20-mm2 #4) EIP is at __make_request+0xeb/0x2d7 eax: ebx: ecx: edx: 00010585 esi: dff497d4 edi: c1974d54 ebp: c1947200 esp: ec6b1b1c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process firefox-bin (pid: 10937, ti=ec6b task=c1938540 task.ti=ec6b) Stack: c1947200 dff4c494 0008 0100 c1947200 dff497d4 c01f1778 ef4c15c0 00672810 ef07c9a0 0008 ef7de6b8 c1948d8c 00200202 c192dc00 000112d0 00200202 c017c700 0001 c1947200 Call Trace: [c01f1778] generic_make_request+0x18d/0x1bb [c017c700] do_mpage_readpage+0x44e/0x454 [c01f343e] submit_bio+0xc3/0xca [c0192124] ext3_get_block+0xa8/0xbe [c017c75b] mpage_end_io_read+0x0/0x61 [c017bd81] mpage_bio_submit+0x19/0x1d [c017c5fe] do_mpage_readpage+0x34c/0x454 [c0179168] bio_add_page+0x31/0x37 [c019207c] ext3_get_block+0x0/0xbe [c013e2b9] add_to_page_cache+0x37/0xa7 [c017c8d1] mpage_readpages+0xb2/0x119 [c019207c] ext3_get_block+0x0/0xbe [c02781d4] ata_qc_issue_prot+0xfe/0x234 [c0275255] ata_qc_issue+0x43b/0x48d [c02795ca] ata_scsi_rw_xlat+0x126/0x19c [c01915f4] ext3_readpages+0x0/0x15 [c0144143] __do_page_cache_readahead+0x16a/0x237 [c019207c] ext3_get_block+0x0/0xbe [c026bce9] scsi_prep_fn+0x1b5/0x227 [c01fbdfb] radix_tree_scan_hole_backward+0x17/0x2d [c0144799] try_context_based_readahead+0x307/0x336 [c0102dbc] __switch_to+0x161/0x17b [c01442c9] ra_submit+0xb9/0xc5 [c0144a9b] page_cache_readahead_adaptive+0x2d3/0x4a4 [c036552a] io_schedule+0x4e/0x57 [c013e066] file_read_actor+0x79/0xca [c013e7f8] do_generic_mapping_read+0x1a4/0x4f3 [c01409ad] generic_file_aio_read+0x1af/0x1f6 [c013dfed] file_read_actor+0x0/0xca [c01efb84] elv_next_request+0x105/0x114 [c015af8f] do_sync_read+0xc7/0x10a [c026b50c] scsi_next_command+0x25/0x2f [c0128560] wake_bit_function+0x0/0x44 [c015defe] sys_fstat64+0x1e/0x23 [c015aec8] do_sync_read+0x0/0x10a [c015b6f2] vfs_read+0x88/0x10a [c015ba3a] sys_read+0x41/0x67 [c0103cce] sysenter_past_esp+0x5f/0x85 [c036] inet6_synq_hash+0xe0/0xf5 === Code: 83 f8 02 75 0d 89 e9 89 da 89 f0 e8 82 ec ff ff eb 0e 48 75 13 89 e9 89 da 89 f0 e8 f0 e9 ff ff 85 c0 0f 85 e5 01 00 00 8b 5b 04 8b 43 04 0f 18 00 90 8d 47 14 39 c3 75 be fa 89 e0 25 00 e0 ff EIP: [c01f369b] __make_request+0xeb/0x2d7 SS:ESP 0068:ec6b1b1c This time i had to wait a few hours till the Bug jumped on. I am trying to make a bisection search, without the patches, but i am not that experienced. HTH Oli My .config is as follows: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-mm2 # Wed Feb 28 04:18:00 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y # CONFIG_RCU_TRACE is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 #
RE: lanana: Add major/minor entries for PPC QE UART devices
Mathiasen, Torben wrote: Got around looking at this one. I'm fine with this approach, but the CPM5 fix looks wrong. Shouldn't it be: 49 = /dev/ttyCPM3 PPC CPM (SCC or SMC) - port 3 instead? Well, how many CPM devices can exist? If there are really 6 ports possible, they need minors up to 51. Also, if QE really is just CPM v3, and they share the same minors, why change the name? Assuming QE has 4 entries, I would expect CPM to be the same. But we need verification of that. If it needs 6, we are in more trouble. Torben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with freezable workqueues
On Wed, Feb 28, 2007 at 12:11:03PM +0100, Rafael J. Wysocki wrote: In addition to thawing worker thread before kthread_stopping it, there are minor changes required in worker threads, to check for is_cpu_offline(bind_cpu) when they come out of refrigerator and jump to wait_to_die if so (ex: softirq.c). I guess you would need these changes before freezer-based hotplug is merged, in which case Gautham can send those patches out first. Yes, please, if that's possible. After looking at the current workqueue code, the above minor change I suggested is not required. So you should be able to fix your kthread_stop on a frozen worker thread hangs problem by just a simple patch like this (against 2.6.20-mm2): --- workqueue.c.org 2007-02-28 18:32:48.0 +0530 +++ workqueue.c 2007-02-28 18:44:23.0 +0530 @@ -718,6 +718,8 @@ static void cleanup_workqueue_thread(str insert_wq_barrier(cwq, barr, 1); cwq-should_stop = 1; alive = 1; + if (frozen(cwq-thread)) + thaw(cwq-thread); } spin_unlock_irq(cwq-lock); Can you test with this? Note that as Oleg commented, freezable workqueues are broken w/o his patch here: http://marc.theaimsgroup.com/?l=linux-kernelm=116855740612755 So you need to have Andrew/Linux pick up the above patch first to have correctly functioning freezable workqueues. -- Regards, vatsa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a bug in AS scheduler?
On 2/28/07, Jens Axboe [EMAIL PROTECTED] wrote: On Tue, Feb 27 2007, Xiaoning Ding wrote: Hi, I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c). In function as_close_req, variable delay is in millisecond, while ad-antic_expire is in jiffies. Doesn't the comparison of delay and ad-antic_expire make any problem? The related source code is quoted blow: if (ad-antic_status == ANTIC_OFF || !ad-ioc_finished) delay = 0; else delay = ((jiffies - ad-antic_start) * 1000) / HZ; antic_start is in jiffies, the difference is here multiplied by 1000 and divided by HZ to turn it into msecs. so delay is in msecs. I am pretty sure Xiaoning was talking about antic_expire, particularly this comparison: else if (delay = 20 delay = ad-antic_expire) regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.20-rt1, yum/rpm
Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo Molnar wrote: i have released the v2.6.20-rt1 kernel, which can be downloaded from the usual place: I have a couple of questions regarding priorities of the softirqs, IRQ handlers, etc. With some exceptions, back in 2.6.18 and prior patches the IRQ threads were prioritized between 50 and 25 and the most of the softirqs were prioritized at 1? In newer patches it looks like they are all prioritized at 50? I was just curious what went into making these choices? I am just trying to better understand these decisions. The basically random order-of-request_irq() prioritization was causing problems (it worked for some but didnt work for others), so i got rid of trying to auto-guess some priority order. Also, now that we've got tools/scripts like set_kthread_prio and rtprio it seemed more consistent to just not attempt to prioritize interrupts and softirqs at all, but to keep them all 'in the middle' of the RT priority range. Ingo Thanks. -- kr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] killing the NR_IRQS arrays.
On Wednesday 28 February 2007, Eric W. Biederman wrote:
Arnd Bergmann [EMAIL PROTECTED] writes:
Introducing the irq_request() etc. functions that take a struct irq*
instead of an int sounds good, but I'd hope we can avoid using those
in device drivers and do a separate abstraction for each bus_type
that deals with interrupts. I'm not sure if that's possible for
each bus_type, but the ones I have worked with in the past should
allow that:
pci: each device/function has a unique irq, drivers need not know
about it afaics.
Then there is msi and with msi-x you can have up to 4K irqs.
I have to admit I still don't really understand how this works
at all. Can a driver that uses msi-x have different handlers
for each of those interrupts registered simultaneously?
I would expect that instead there should be only one 'struct irq'
for the device, with the handler getting a 12 bit number argument.
s390: got rid of irq numbers already
Yes. I should really look at that more and see if I could bring
s390 into the generic irq code with my planned changes.
I don't think there is much point in changing the s390 code, but
the way it is solved there may be interesting for other buses
as well. The interrupt handler there is not being registered
explicitly, but is part of the driver (in case of subchannel)
or of the device (in case of ccw_device) data structure.
Similarly, in a pci device, one could imagine that the
struct pci_driver contains a irq_handler_t member that
is registered from the pci_device_probe() function
if present.
Note that we can even start converting device drivers first, before
moving away from irq numbers. A typical PCI driver should get
somewhat simpler by the conversion, and when they are all converted,
we can replace pci_dev-irq with a struct irq* under the covers.
Reasonable if it is easy and straight forward.
Something like pci_request_irq(dev,) and the helper looks at
dev-irq under the covers and calls request_irq or whatever makes
sense. Is this what you are thinking. Examples would help me here.
Ok, I had an example in on of my previous posts, but based on the
discussion since then, it has become significantly simpler, basically
reducing the work to
struct irq *pci_irq_request(struct pci_device *dev,
irq_handler_t handler)
{
if (!dev-irq)
return -ENODEV;
return irq_request(irq, handler, IRQF_SHARED,
dev-driver-name, dev);
}
int pci_irq_free(struct pci_device *dev)
{
return irq_free(dev-irq, dev);
}
The most significant change of this to the current code
would be that we can pass arguments down to irq_request
automatically, e.g. the irq handler can always get the
pci_device as its dev_id.
For talking to user space I expect we will have numbers for a long time
to come yet.
I was wondering about that. Do you only mean /proc/interrupts or
are there other user interfaces we need to worry about?
For /proc/interrupts, what could break if we have interrupt numbers
only local to each controller and potentially duplicate numbers
in the list? It's good to be paranoid about changes to proc files,
but I can definitely see value in having meaningful interrupt
numbers in there instead of making up a more or less random mapping
to a flat number space.
Arnd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] killing the NR_IRQS arrays.
pci: each device/function has a unique irq, drivers need not know about it afaics. Then there is msi and with msi-x you can have up to 4K irqs. I have to admit I still don't really understand how this works at all. Can a driver that uses msi-x have different handlers for each of those interrupts registered simultaneously? Yes. It doesn't have to, though. I would expect that instead there should be only one 'struct irq' for the device, with the handler getting a 12 bit number argument. Why? The device really generates many different interrupts, why hide this fact. For talking to user space I expect we will have numbers for a long time to come yet. I was wondering about that. Do you only mean /proc/interrupts or are there other user interfaces we need to worry about? There's the IRQ affinity stuff too. For /proc/interrupts, what could break if we have interrupt numbers only local to each controller and potentially duplicate numbers in the list? It's good to be paranoid about changes to proc files, but I can definitely see value in having meaningful interrupt numbers in there instead of making up a more or less random mapping to a flat number space. Duplicate all this stuff into /sys in a sane format (*) and wait until userland catches up, then throw away the /proc interfaces. It'll take a while, and until that day you will have to keep *some* interrupt number - interrupt bijection. Userland tools that think they know what interrupt number should be what are dead already. (*) i.e., exposing the interrupt tree as a tree, cascaded controllers and all. Segher - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/26] Xen-paravirt_ops: Add pagetable accessors to pack and unpack pagetable entries
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: +#ifdef CONFIG_PARAVIRT +/* After pte_t, etc, have been defined */ +#include asm/paravirt.h +#endif hm - there's already a CONFIG_PARAVIRT conditional in asm-i386/paravirt.h. Yes, but it happens after asm/paravirt.h has already included some things, and it ends up causing problems. paravirt.h still defines various stub functions in the !CONFIG_PARAVIRT case, so it needs to do the includes either way. hm, it then needs to be fixed first, instead of adding to the mess. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: be sure to trim blocks after direct_io has failed
This is updated version of patch aimed to fix direct_io error handling issue
i've previously sent 2 wheeks ago. If you don't like anything in this patch
plese let me know.
Changes:
- comments added. I think now it is clearly describe things.
- patch prepared against 2.6.20-mm2
How this patch tested:
- LTP test, and other readv/writev op tests.
- fsstress test.
- manual direct_io tests.
Log:
- Move common segment checks to separate helper function.
- Trim off blocks after generic_file_direct_write() has failed.
- Update out of date comments about direct_io locking rules.
Signed-off-by: Monakhov Dmitriy [EMAIL PROTECTED]
---
mm/filemap.c | 107 +++--
1 files changed, 66 insertions(+), 41 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index a9284c2..c81184c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1147,6 +1147,38 @@ success:
return size;
}
+/*
+ * Performs necessary checks before doing a write
+ *
+ * Adjust number of segments and amount of bytes to write.
+ * Returns appropriate error code that caller should return or
+ * zero in case that write should be allowed.
+ */
+int generic_segment_checks(const struct iovec *iov, unsigned long *nr_segs,
+ size_t *count, unsigned long access_flags)
+{
+ unsigned long seg;
+ for (seg = 0; seg *nr_segs; seg++) {
+ const struct iovec *iv = iov[seg];
+
+ /*
+* If any segment has a negative length, or the cumulative
+* length ever wraps negative then return -EINVAL.
+*/
+ *count += iv-iov_len;
+ if (unlikely((ssize_t)(*count|iv-iov_len) 0))
+ return -EINVAL;
+ if (access_ok(access_flags, iv-iov_base, iv-iov_len))
+ continue;
+ if (seg == 0)
+ return -EFAULT;
+ *nr_segs = seg;
+ *count -= iv-iov_len; /* This segment is no good */
+ break;
+ }
+ return 0;
+}
+
/**
* generic_file_aio_read - generic filesystem read routine
* @iocb: kernel I/O control block
@@ -1168,24 +1200,9 @@ generic_file_aio_read(struct kiocb *iocb, const struct
iovec *iov,
loff_t *ppos = iocb-ki_pos;
count = 0;
- for (seg = 0; seg nr_segs; seg++) {
- const struct iovec *iv = iov[seg];
-
- /*
-* If any segment has a negative length, or the cumulative
-* length ever wraps negative then return -EINVAL.
-*/
- count += iv-iov_len;
- if (unlikely((ssize_t)(count|iv-iov_len) 0))
- return -EINVAL;
- if (access_ok(VERIFY_WRITE, iv-iov_base, iv-iov_len))
- continue;
- if (seg == 0)
- return -EFAULT;
- nr_segs = seg;
- count -= iv-iov_len; /* This segment is no good */
- break;
- }
+ retval = generic_segment_checks(iov, nr_segs, count, VERIFY_WRITE);
+ if (retval)
+ return retval;
/* coalesce the iovecs and go direct-to-BIO for O_DIRECT */
if (filp-f_flags O_DIRECT) {
@@ -2080,8 +2097,9 @@ generic_file_direct_write(struct kiocb *iocb, const
struct iovec *iov,
/*
* Sync the fs metadata but not the minor inode changes and
* of course not the data as we did direct DMA for the IO.
-* i_mutex is held, which protects generic_osync_inode() from
-* livelocking. AIO O_DIRECT ops attempt to sync metadata here.
+* i_mutex may not being held, if so some specific locking
+* ordering must protect generic_osync_inode() from livelocking.
+* AIO O_DIRECT ops attempt to sync metadata here.
*/
if ((written = 0 || written == -EIOCBQUEUED)
((file-f_flags O_SYNC) || IS_SYNC(inode))) {
@@ -2271,30 +2289,14 @@ __generic_file_aio_write_nolock(struct kiocb *iocb,
const struct iovec *iov,
size_t ocount; /* original count */
size_t count; /* after file limit checks */
struct inode*inode = mapping-host;
- unsigned long seg;
loff_t pos;
ssize_t written;
ssize_t err;
ocount = 0;
- for (seg = 0; seg nr_segs; seg++) {
- const struct iovec *iv = iov[seg];
-
- /*
-* If any segment has a negative length, or the cumulative
-* length ever wraps negative then return -EINVAL.
-*/
- ocount += iv-iov_len;
- if (unlikely((ssize_t)(ocount|iv-iov_len) 0))
- return -EINVAL;
- if (access_ok(VERIFY_READ, iv-iov_base, iv-iov_len))
- continue;
- if (seg == 0)
-
Re: Problem with freezable workqueues
On Wed, Feb 28, 2007 at 06:47:21PM +0530, Srivatsa Vaddagiri wrote: --- workqueue.c.org 2007-02-28 18:32:48.0 +0530 +++ workqueue.c 2007-02-28 18:44:23.0 +0530 @@ -718,6 +718,8 @@ static void cleanup_workqueue_thread(str insert_wq_barrier(cwq, barr, 1); cwq-should_stop = 1; alive = 1; + if (frozen(cwq-thread)) + thaw(cwq-thread); I meant thaw_process(cwq-thread) } spin_unlock_irq(cwq-lock); -- Regards, vatsa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.21-rc1: CIFS cheers, NFS4 jeers
Florin Iucha wrote: On Tue, Feb 27, 2007 at 09:36:23PM -0500, Bill Davidsen wrote: Florin Iucha wrote: Hello, it's me and my 70 GB of photos again. I have tested both CIFS and NFSv4 clients in kernel 2.6.20-rc1 . CIFS passed with flying colors and NFSv4 stalled after 7 GB. Neil has been diddling NFS, I did some light testing with 2.6.20-git14 with 190GB of mp3 and mpg files (library of congress folk music) without hangs. Just did it work tests, copy 20-30GB to server, do md5 on the data pulled back from the server. Didn't hang, performance testing later. 2.6.20-rcX used to copy all files then hang on certain operations that I think used the VFS. 2.6.21-rc1 stalls the NFS transfer itself after several GB. The data was never corrupted. Have you tried copying _ALL_ 190 GB to the server? No, but as noted I was doing 20-30GB, so if several is a small number I'm not seeing that behavior. I'm using a Gbit connection if that is not the same as your setup. I have additional testing queued for time available this week. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a bug in AS scheduler?
On Wed, Feb 28 2007, Benoit Boissinot wrote: On 2/28/07, Jens Axboe [EMAIL PROTECTED] wrote: On Tue, Feb 27 2007, Xiaoning Ding wrote: Hi, I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c). In function as_close_req, variable delay is in millisecond, while ad-antic_expire is in jiffies. Doesn't the comparison of delay and ad-antic_expire make any problem? The related source code is quoted blow: if (ad-antic_status == ANTIC_OFF || !ad-ioc_finished) delay = 0; else delay = ((jiffies - ad-antic_start) * 1000) / HZ; antic_start is in jiffies, the difference is here multiplied by 1000 and divided by HZ to turn it into msecs. so delay is in msecs. I am pretty sure Xiaoning was talking about antic_expire, particularly this comparison: else if (delay = 20 delay = ad-antic_expire) Ah, I misread the name. That does look like a bug, antic_expire is in jiffies. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/4] improve alternative instruction code and optimize get_cycles_sync
This series of patches extend the alternative instructions framework on i386 and x86_64 architectures to support two alternative instruction replacements. This code is used together with the introduction of the X86_FEATURE_SYNC_RDTSC flag on i386 to simplify and optimize the get_cycles_sync() function. The optimization changes this function to use RDTSCP instead of CPUID;RDTSC if this instruction is available. Don't use CPUID there is really important if the kernel runs as a KVM guest, because this instruction is intercepted and causes an expensive VMEXIT. -- Joerg Roedel Operating System Research Center AMD Saxony LLC Co. KG - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] i386: extend alternative instructions framework
From: Joerg Roedel [EMAIL PROTECTED]
This patch extends the alternative instructions framework to support 2
alternative instructions.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
--
Joerg Roedel
Operating System Research Center
AMD Saxony LLC Co. KG
diff --git a/arch/i386/kernel/alternative.c b/arch/i386/kernel/alternative.c
index 9eca21b..59f1770 100644
--- a/arch/i386/kernel/alternative.c
+++ b/arch/i386/kernel/alternative.c
@@ -153,14 +153,23 @@ extern u8 __smp_alt_begin[], __smp_alt_end[];
void apply_alternatives(struct alt_instr *start, struct alt_instr *end)
{
struct alt_instr *a;
- u8 *instr;
+ u8 *instr, *replacement;
+ u8 replacementlen;
int diff;
DPRINTK(%s: alt table %p - %p\n, __FUNCTION__, start, end);
for (a = start; a end; a++) {
- BUG_ON(a-replacementlen a-instrlen);
- if (!boot_cpu_has(a-cpuid))
+ if (boot_cpu_has(a-cpuid)) {
+ replacement = a-replacement;
+ replacementlen = a-replacementlen;
+ } else if ((a-replacementlen2 0)
+ (boot_cpu_has(a-cpuid2))) {
+ replacement = a-replacement2;
+ replacementlen = a-replacementlen2;
+ } else
continue;
+
+ BUG_ON(replacementlen a-instrlen);
instr = a-instr;
#ifdef CONFIG_X86_64
/* vsyscall code is not mapped yet. resolve it manually. */
@@ -170,9 +179,9 @@ void apply_alternatives(struct alt_instr *start, struct
alt_instr *end)
__FUNCTION__, a-instr, instr);
}
#endif
- memcpy(instr, a-replacement, a-replacementlen);
- diff = a-instrlen - a-replacementlen;
- nop_out(instr + a-replacementlen, diff);
+ memcpy(instr, replacement, replacementlen);
+ diff = a-instrlen - replacementlen;
+ nop_out(instr + replacementlen, diff);
}
}
diff --git a/include/asm-i386/alternative.h b/include/asm-i386/alternative.h
index b8fa955..4a77e93 100644
--- a/include/asm-i386/alternative.h
+++ b/include/asm-i386/alternative.h
@@ -10,11 +10,14 @@
struct alt_instr {
u8 *instr; /* original instruction */
u8 *replacement;
+ u8 *replacement2;
u8 cpuid; /* cpuid bit set for replacement */
+ u8 cpuid2; /* cpuid bit set for replacement2 */
u8 instrlen; /* length of original instruction */
u8 replacementlen; /* length of new instruction, = instrlen */
- u8 pad;
-};
+ u8 replacementlen2;
+ u8 pad[3];
+} __attribute__ ((packed));
extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
@@ -36,6 +39,12 @@ static inline void alternatives_smp_switch(int smp) {}
#endif
/*
+ * use this macro(s) if you need more than one output parameter
+ * in alternative_io_*
+ */
+#define ASM_OUTPUT2(a, b) a, b
+
+/*
* Alternative instructions for different CPU types or capabilities.
*
* This allows to use optimized instructions even on generic binary
@@ -53,9 +62,12 @@ static inline void alternatives_smp_switch(int smp) {}
.align 4\n\
.long 661b\n/* label */ \
.long 663f\n/* new instruction */ \
+ .long 0x00\n \
.byte %c0\n /* feature bit */ \
+ .byte 0x00\n \
.byte 662b-661b\n /* sourcelen */ \
.byte 664f-663f\n /* replacementlen */ \
+ .byte 0x00\n \
.previous\n \
.section .altinstr_replacement,\ax\\n \
663:\n\t newinstr \n664:\n /* replacement */\
@@ -77,14 +89,38 @@ static inline void alternatives_smp_switch(int smp) {}
.align 4\n\
.long 661b\n/* label */ \
.long 663f\n/* new instruction */ \
+ .long 0x00\n \
.byte %c0\n /* feature bit */ \
+ .byte 0x00\n \
.byte 662b-661b\n /* sourcelen */ \
.byte 664f-663f\n /* replacementlen */ \
+ .byte 0x00\n \
.previous\n \
.section
Question on tty line discipline
Hi, I have a question concerning the line discipline behaviour for serial devices. When the line discipline is set via ioctl from user space to e.g. N_PPP and the userspace program returns without resetting the line discipline back to N_TTY, the serial device cannot be used (ENODV) until an appropriate ioctl (to N_TTY) is performed. Is there any reason for the fact that the line discipline is not reset by the kernel , when closing the device. Could you please CC me on answers and comments ? Kind regards, Christopher Meller -- Christopher Meller Software engineer Innominate Security Technologies AG protecting industrial networks tel: +49.30.6392-3680 fax: +49.30.6392-3307 Albert-Einstein-Str. 14 D-12489 Berlin www.innominate.com Register Court: AG Charlottenburg, HR B 81603 Management Board: Joachim Fietz, Dirk Seewald Chairman of the Supervisory Board: Edward M. Stadum - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] x86_64: changes to x86_64 architecture for alternative instruction improvements
From: Joerg Roedel [EMAIL PROTECTED]
In this patch updates the x86_64 architecture to work with the changes
to alternative instructions in i386
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
--
Joerg Roedel
Operating System Research Center
AMD Saxony LLC Co. KG
diff --git a/arch/x86_64/lib/clear_page.S b/arch/x86_64/lib/clear_page.S
index 9a10a78..ab525ee 100644
--- a/arch/x86_64/lib/clear_page.S
+++ b/arch/x86_64/lib/clear_page.S
@@ -53,7 +53,10 @@ ENDPROC(clear_page)
.align 8
.quad clear_page
.quad 1b
+ .quad 0
.byte X86_FEATURE_REP_GOOD
+ .byte 0
.byte .Lclear_page_end - clear_page
.byte 2b - 1b
+ .byte 0
.previous
diff --git a/arch/x86_64/lib/copy_page.S b/arch/x86_64/lib/copy_page.S
index 727a5d4..b4d0329 100644
--- a/arch/x86_64/lib/copy_page.S
+++ b/arch/x86_64/lib/copy_page.S
@@ -113,7 +113,10 @@ ENDPROC(copy_page)
.align 8
.quad copy_page
.quad 1b
+ .quad 0
.byte X86_FEATURE_REP_GOOD
+ .byte 0
.byte .Lcopy_page_end - copy_page
.byte 2b - 1b
+ .byte 0
.previous
diff --git a/arch/x86_64/lib/copy_user.S b/arch/x86_64/lib/copy_user.S
index 70bebd3..d505df3 100644
--- a/arch/x86_64/lib/copy_user.S
+++ b/arch/x86_64/lib/copy_user.S
@@ -27,9 +27,12 @@
.align 8
.quad 0b
.quad 2b
+ .quad 0
.byte \feature /* when feature is set */
+ .byte 0
.byte 5
.byte 5
+ .byte 0
.previous
.endm
diff --git a/arch/x86_64/lib/memcpy.S b/arch/x86_64/lib/memcpy.S
index 0ea0ddc..b1e1686 100644
--- a/arch/x86_64/lib/memcpy.S
+++ b/arch/x86_64/lib/memcpy.S
@@ -123,7 +123,10 @@ ENDPROC(__memcpy)
.align 8
.quad memcpy
.quad 1b
+ .quad 0
.byte X86_FEATURE_REP_GOOD
+ .byte 0
.byte .Lfinal - memcpy
.byte 2b - 1b
+ .byte 0
.previous
diff --git a/arch/x86_64/lib/memset.S b/arch/x86_64/lib/memset.S
index 2c59481..566e179 100644
--- a/arch/x86_64/lib/memset.S
+++ b/arch/x86_64/lib/memset.S
@@ -127,7 +127,10 @@ ENDPROC(__memset)
.align 8
.quad memset
.quad 1b
+ .quad 0
.byte X86_FEATURE_REP_GOOD
+ .byte 0
.byte .Lfinal - memset
.byte 2b - 1b
+ .byte 0
.previous
diff --git a/include/asm-x86_64/alternative.h b/include/asm-x86_64/alternative.h
index a6657b4..63cd8e5 100644
--- a/include/asm-x86_64/alternative.h
+++ b/include/asm-x86_64/alternative.h
@@ -10,11 +10,14 @@
struct alt_instr {
u8 *instr; /* original instruction */
u8 *replacement;
+ u8 *replacement2;
u8 cpuid; /* cpuid bit set for replacement */
+ u8 cpuid2; /* cpuid bit set for replacement2 */
u8 instrlen; /* length of original instruction */
u8 replacementlen; /* length of new instruction, = instrlen */
- u8 pad[5];
-};
+ u8 replacementlen2;
+ u8 pad[3];
+} __attribute__ ((packed));
extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
@@ -36,6 +39,12 @@ static inline void alternatives_smp_switch(int smp) {}
#endif
+/*
+ * use this macro(s) if you need more than one output parameter
+ * in alternative_io_*
+ */
+#define ASM_OUTPUT2(a, b) a, b
+
/*
* Alternative instructions for different CPU types or capabilities.
*
@@ -54,9 +63,12 @@ static inline void alternatives_smp_switch(int smp) {}
.align 8\n \
.quad 661b\n/* label */ \
.quad 663f\n/* new instruction */ \
+ .quad 0x00\n \
.byte %c0\n /* feature bit */\
+ .byte 0x00\n \
.byte 662b-661b\n /* sourcelen */ \
.byte 664f-663f\n /* replacementlen */ \
+ .byte 0x00\n \
.previous\n \
.section .altinstr_replacement,\ax\\n \
663:\n\t newinstr \n664:\n /* replacement */ \
@@ -78,9 +90,12 @@ static inline void alternatives_smp_switch(int smp) {}
.align 8\n\
.quad 661b\n/* label */ \
.quad 663f\n/* new instruction */ \
+ .quad 0x00\n \
.byte %c0\n /* feature bit */ \
+ .byte 0x00\n \
.byte 662b-661b\n /* sourcelen */ \
[PATCH 4/4] optimize and simplify get_cycles_sync()
From: Joerg Roedel [EMAIL PROTECTED]
This patch simplifies the get_cycles_sync() function by removing the
#ifdefs from it. Further it introduces an optimization for AMD
processors. There the RDTSCP instruction is used instead of CPUID;RDTSC
which is helpfull if the kernel runs as a KVM guest. Running as a guest
makes CPUID very expensive because it causes an intercept of the guest.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
--
Joerg Roedel
Operating System Research Center
AMD Saxony LLC Co. KG
diff --git a/include/asm-i386/cpufeature.h b/include/asm-i386/cpufeature.h
index 3f92b94..a9f1f01 100644
--- a/include/asm-i386/cpufeature.h
+++ b/include/asm-i386/cpufeature.h
@@ -49,6 +49,7 @@
#define X86_FEATURE_MP (1*32+19) /* MP Capable. */
#define X86_FEATURE_NX (1*32+20) /* Execute Disable */
#define X86_FEATURE_MMXEXT (1*32+22) /* AMD MMX extensions */
+#define X86_FEATURE_RDTSCP (1*32+27) /* RDTSCP */
#define X86_FEATURE_LM (1*32+29) /* Long Mode (x86-64) */
#define X86_FEATURE_3DNOWEXT (1*32+30) /* AMD 3DNow! extensions */
#define X86_FEATURE_3DNOW (1*32+31) /* 3DNow! */
diff --git a/include/asm-x86_64/tsc.h b/include/asm-x86_64/tsc.h
index 9a0a368..05df3f6 100644
--- a/include/asm-x86_64/tsc.h
+++ b/include/asm-x86_64/tsc.h
@@ -34,22 +34,15 @@ static inline cycles_t get_cycles(void)
/* Like get_cycles, but make sure the CPU is synchronized. */
static __always_inline cycles_t get_cycles_sync(void)
{
- unsigned long long ret;
-#ifdef X86_FEATURE_SYNC_RDTSC
- unsigned eax;
+ unsigned int a, d;
- /*
-* Don't do an additional sync on CPUs where we know
-* RDTSC is already synchronous:
-*/
- alternative_io(cpuid, ASM_NOP2, X86_FEATURE_SYNC_RDTSC,
- =a (eax), 0 (1) : ebx,ecx,edx,memory);
-#else
- sync_core();
-#endif
- rdtscll(ret);
+ alternative_io_two(cpuid\nrdtsc,
+ rdtsc, X86_FEATURE_SYNC_RDTSC,
+ rdtscp, X86_FEATURE_RDTSCP,
+ ASM_OUTPUT2(=a (a), =d (d)),
+ 0 (1) : ecx, memory);
- return ret;
+ return ((unsigned long long)a) | (((unsigned long long)d)32);
}
extern void tsc_init(void);
struct page field arrangement
A change early last year reordered struct page so that ptl overlaps not only private, but also mapping. Since spinlock_t can be much larger, I'm wondering whether there's a reason to not also overlay the space index and lru take - are these used for anything on page table pages? Thanks, 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: Question on tty line discipline
On Wed, 28 Feb 2007 14:47:12 +0100 Christopher Meller [EMAIL PROTECTED] wrote: Hi, I have a question concerning the line discipline behaviour for serial devices. When the line discipline is set via ioctl from user space to e.g. N_PPP and the userspace program returns without resetting the line discipline back to N_TTY, the serial device cannot be used (ENODV) until an appropriate ioctl (to N_TTY) is performed. Is there any reason for the fact that the line discipline is not reset by the kernel , when closing the device. No special reason, it has simply always been that way. Getty and friends are expected to put the tty back into a sane state. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 7:14 AM, Mathiasen, Torben wrote: Mathiasen, Torben wrote: Got around looking at this one. I'm fine with this approach, but the CPM5 fix looks wrong. Shouldn't it be: 49 = /dev/ttyCPM3 PPC CPM (SCC or SMC) - port 3 instead? Well, how many CPM devices can exist? If there are really 6 ports possible, they need minors up to 51. Also, if QE really is just CPM v3, and they share the same minors, why change the name? Assuming QE has 4 entries, I would expect CPM to be the same. But we need verification of that. If it needs 6, we are in more trouble. I think it really is 6 for the current CPM, and I don't see why we its not 8 for QE, Timur? - k - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
Segher Boessenkool wrote: 46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0 ... - 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 + 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 If CPM0 is 46, then CPM5 is not 47, but not 49 either. Unless it's not CPM5 but CPM3? Honestly, I don't know. I was just correcting the obvious typo (47 instead of 49). I'll try to get an answer from someone, but I'm no CPM expert. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sound 2.6.19: Soundcard driver often fail to load?
On 2/27/07, Veronique Vincent [EMAIL PROTECTED] wrote: Maybie the Fedora team should use the asound.conf configuration instead? This doesn't work for apps that use the deprecated /dev/dsp API. Of course, a modern distro should be trying to purge these anyway... Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
H. Peter Anvin wrote: Also, if QE really is just CPM v3, and they share the same minors, why change the name? Because the QE isn't called CPM v3, that's just one way to think about it. It's a different device that has some backwards compatibility, but the drivers are all distinct and they all use QE and not CPM in their names. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.20 SATA error
On Wed, 28 Feb 2007, Robert Hancock wrote: Gerhard Mack wrote: hello, Can someone tell me what this means? ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/100 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Some command timed out, apparently. From this one can't easily say why. Please send full dmesg. Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #10 SMP PREEMPT Mon Feb 26 14:48:53 EST 2007 Command line: root=/dev/sda3 ro BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3def (usable) BIOS-e820: 3def - 3def3000 (ACPI NVS) BIOS-e820: 3def3000 - 3df0 (ACPI data) BIOS-e820: 3e00 - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 253680) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP (v002 Nvidia) @ 0x000f7560 ACPI: XSDT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3def30c0 ACPI: FADT (v003 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3defb3c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3defb5c0 ACPI: HPET (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x0098) @ 0x3defb840 ACPI: MCFG (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3defb8c0 ACPI: MADT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3defb500 ACPI: DSDT (v001 NVIDIA ASUSACPI 0x1000 MSFT 0x010e) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 253680) 1 entries of 256 used Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 253680 On node 0 totalpages: 253583 DMA zone: 56 pages used for memmap DMA zone: 1831 pages reserved DMA zone: 2112 pages, LIFO batch:0 DMA32 zone: 3412 pages used for memmap DMA32 zone: 246172 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 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 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat ACPI: HPET id: 0x10de8201 base: 0xfefff000 Using ACPI (MADT) for SMP configuration information Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000f Nosave address range: 000f - 0010 Allocating PCI resources starting at 5000 (gap: 4000:a000) PERCPU: Allocating 33152 bytes of per cpu data Built 1 zonelists. Total pages: 248284 Kernel command line: root=/dev/sda3 ro Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... CPU 0: aperture @ fa9c00 size 32 MB Aperture too small (32 MB) No AGP bridge found Memory: 991204k/1014720k available (3834k kernel code, 22888k reserved, 2637k data, 256k init) Calibrating delay using timer specific routine.. 4413.54 BogoMIPS (lpj=2206772) Security Framework v1.0.0 initialized Capability LSM initialized Failure registering Root Plug module with the kernel Failure
RE: lanana: Add major/minor entries for PPC QE UART devices
Mathiasen, Torben wrote: Assuming QE has 4 entries, I would expect CPM to be the same. But we need verification of that. If it needs 6, we are in more trouble. The QE can have up to 8, actually, but I'm willing to limit the driver to 4. Its your choice if you want to limit it to 4 or have it moved into a different minor range. I can live with both. Thanks, Torben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] i386: add the X86_FEATURE_SYNC_RDTSC flag
From: Joerg Roedel [EMAIL PROTECTED]
This patch adds the X86_FEATURE_SYNC_RDTSC to the i386 architecture.
This is very helpfull to simplify the get_cycles_sync() function and
remove the #ifdefs from it.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
--
Joerg Roedel
Operating System Research Center
AMD Saxony LLC Co. KG
diff --git a/arch/i386/kernel/cpu/amd.c b/arch/i386/kernel/cpu/amd.c
index 41cfea5..11f5730 100644
--- a/arch/i386/kernel/cpu/amd.c
+++ b/arch/i386/kernel/cpu/amd.c
@@ -241,6 +241,8 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
if (cpuid_eax(0x8000) = 0x8006)
num_cache_leaves = 3;
+
+ clear_bit(X86_FEATURE_SYNC_RDTSC, c-x86_capability);
}
static unsigned int __cpuinit amd_size_cache(struct cpuinfo_x86 * c, unsigned
int size)
diff --git a/arch/i386/kernel/cpu/intel.c b/arch/i386/kernel/cpu/intel.c
index 56fe265..403a495 100644
--- a/arch/i386/kernel/cpu/intel.c
+++ b/arch/i386/kernel/cpu/intel.c
@@ -188,8 +188,11 @@ static void __cpuinit init_intel(struct cpuinfo_x86 *c)
}
#endif
- if (c-x86 == 15)
+ if (c-x86 == 15) {
set_bit(X86_FEATURE_P4, c-x86_capability);
+ set_bit(X86_FEATURE_SYNC_RDTSC, c-x86_capability);
+ } else
+ clear_bit(X86_FEATURE_SYNC_RDTSC, c-x86_capability);
if (c-x86 == 6)
set_bit(X86_FEATURE_P3, c-x86_capability);
if ((c-x86 == 0xf c-x86_model = 0x03) ||
diff --git a/include/asm-i386/cpufeature.h b/include/asm-i386/cpufeature.h
index 3f92b94..a9f1f01 100644
--- a/include/asm-i386/cpufeature.h
+++ b/include/asm-i386/cpufeature.h
@@ -75,6 +76,7 @@
#define X86_FEATURE_ARCH_PERFMON (3*32+11) /* Intel Architectural PerfMon */
#define X86_FEATURE_PEBS (3*32+12) /* Precise-Event Based Sampling */
#define X86_FEATURE_BTS(3*32+13) /* Branch Trace Store */
+#define X86_FEATURE_SYNC_RDTSC (3*32+14) /* RDTSC is serializing */
/* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
#define X86_FEATURE_XMM3 (4*32+ 0) /* Streaming SIMD Extensions-3 */
Re: 2.6.20 SATA error
Gerhard Mack wrote: hello, Can someone tell me what this means? ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/100 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Some command timed out, apparently. From this one can't easily say why. Please send full dmesg. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
Gerhard Mack wrote: ata1.00: configured for UDMA/100 [...] ata1.00: configured for UDMA/66 [...] ata1.00: configured for UDMA/44 [...] ata1.00: configured for UDMA/33 [...] ata1.00: configured for UDMA/25 [...] ata1.00: configured for UDMA/16 [...] ata1.00: configured for PIO4 I have the same problem, though it appears randomly. It seems like the chances for this happening are bigger if I do heavy disk I/O. The only way to fix that is to shut down the computer and wait a few seconds before rebooting (if I don't wait, the problem doesn't go away). I bought new harddrives, so it's most likely not caused by the drives, I also tried putting the drives onto a different controller (I have four on-board SATA controller and two harddrives), that didn't help either, so I suspect its the cable - SATA cables are very error-prone, I don't trust them as they don't hold that tightly in the socket. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 8:51 AM, Mathiasen, Torben wrote: Mathiasen, Torben wrote: Assuming QE has 4 entries, I would expect CPM to be the same. But we need verification of that. If it needs 6, we are in more trouble. The QE can have up to 8, actually, but I'm willing to limit the driver to 4. Its your choice if you want to limit it to 4 or have it moved into a different minor range. I can live with both. I'd rather we support 8 now. - k - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Tomas Carnecky wrote: Gerhard Mack wrote: ata1.00: configured for UDMA/100 [...] ata1.00: configured for UDMA/66 [...] ata1.00: configured for UDMA/44 [...] ata1.00: configured for UDMA/33 [...] ata1.00: configured for UDMA/25 [...] ata1.00: configured for UDMA/16 [...] ata1.00: configured for PIO4 I have the same problem, though it appears randomly. It seems like the chances for this happening are bigger if I do heavy disk I/O. The only way to fix that is to shut down the computer and wait a few seconds before rebooting (if I don't wait, the problem doesn't go away). I bought new harddrives, so it's most likely not caused by the drives, I also tried putting the drives onto a different controller (I have four on-board SATA controller and two harddrives), that didn't help either, so I suspect its the cable - SATA cables are very error-prone, I don't trust them as they don't hold that tightly in Well that's the strange thing.. I've done heavy I/O on this with no trouble. This happened overnight when my system should have been mostly idle Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
Kumar Gala wrote: On Feb 28, 2007, at 8:51 AM, Mathiasen, Torben wrote: Mathiasen, Torben wrote: Assuming QE has 4 entries, I would expect CPM to be the same. But we need verification of that. If it needs 6, we are in more trouble. The QE can have up to 8, actually, but I'm willing to limit the driver to 4. Its your choice if you want to limit it to 4 or have it moved into a different minor range. I can live with both. I'd rather we support 8 now. It sounds like the QE driver should be moved to a separate minor range, and given 8 minors. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fully honor vdso_enabled [i386, sh; x86_64?]
[adding Andi and Ingo]
John Reiser wrote:
Architectures such as i386, sh, x86_64 have a flag /proc/sys/vm/vdso_enabled
to choose whether the kernel should setup a process to use vdso after
execve().
Informing the user code via AT_SYSINFO* is controlled by macro ARCH_DLINFO in
fs/binfmt_elf.c and include/asm-$ARCH/elf.h, but the vdso page is established
always via arch_setup_additonal_pages() called from load_elf_binary().
If vdso_enabled is off, then current code wastes kernel time during execve()
and fragments the address space unnecessarily.
This patch changes arch_setup_additonal_pages() to honor vdso_enabled.
For i386 it also allows the option of a fixed addresss to avoid
fragmenting the address space. Compiles and runs on i386.
x86_64 [IA32 support] and sh maintainers also please comment.
For some related history, including interaction with exec-shield, see:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229304
and also 207020 and 162797.
Signed-off-by: John Reiser [EMAIL PROTECTED]
diff --git a/arch/i386/kernel/sysenter.c b/arch/i386/kernel/sysenter.c
index 13ca54a..f8c4d76 100644
--- a/arch/i386/kernel/sysenter.c
+++ b/arch/i386/kernel/sysenter.c
@@ -22,6 +22,8 @@
#include asm/msr.h
#include asm/pgtable.h
#include asm/unistd.h
+#include asm/a.out.h
+#include asm/mman.h
/*
* Should the kernel map a VDSO page into processes and pass its
@@ -105,10 +107,25 @@ int arch_setup_additional_pages(struct linux_binprm
*bprm, int exstack)
{
struct mm_struct *mm = current-mm;
unsigned long addr;
+ unsigned long flags;
int ret;
+ switch (vdso_enabled) {
+ case 0: /* none */
+ return 0;
+ default:
+ case 1: /* vdso in random available page */
+ addr = 0ul;
+ flags = 0ul;
+ break;
+ case 2: /* out of user's way */
+ addr = STACK_TOP;
+ flags = MAP_FIXED;
+ break;
+ }
+
down_write(mm-mmap_sem);
- addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
+ addr = get_unmapped_area(NULL, addr, PAGE_SIZE, 0, flags);
if (IS_ERR_VALUE(addr)) {
ret = addr;
goto up_fail;
diff --git a/arch/sh/kernel/vsyscall/vsyscall.c
b/arch/sh/kernel/vsyscall/vsyscall.c
index 7b0f66f..2b789fb 100644
--- a/arch/sh/kernel/vsyscall/vsyscall.c
+++ b/arch/sh/kernel/vsyscall/vsyscall.c
@@ -64,6 +64,9 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
unsigned long addr;
int ret;
+ if (!vdso_enabled)
+ return 0;
+
down_write(mm-mmap_sem);
addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
if (IS_ERR_VALUE(addr)) {
diff --git a/include/asm-i386/a.out.h b/include/asm-i386/a.out.h
index ab17bb8..9894f73 100644
--- a/include/asm-i386/a.out.h
+++ b/include/asm-i386/a.out.h
@@ -19,7 +19,7 @@ struct exec
#ifdef __KERNEL__
-#define STACK_TOPTASK_SIZE
+#define STACK_TOP(TASK_SIZE - PAGE_SIZE) /* 1 page optional for vdso */
#endif
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] display class
How does this look? The new and improved display class.
Signed-Off: James Simmons [EMAIL PROTECTED]
diff -urN -X fbdev-2.6/Documentation/dontdiff
linus-2.6/drivers/video/display/display-sysfs.c
fbdev-2.6/drivers/video/display/display-sysfs.c
--- linus-2.6/drivers/video/display/display-sysfs.c 1969-12-31
19:00:00.0 -0500
+++ fbdev-2.6/drivers/video/display/display-sysfs.c 2007-02-28
10:09:47.0 -0500
@@ -0,0 +1,217 @@
+/*
+ * display-sysfs.c - Display output driver sysfs interface
+ *
+ * Copyright (C) 2007 James Simmons [EMAIL PROTECTED]
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~
+ */
+#include linux/module.h
+#include linux/display.h
+#include linux/ctype.h
+#include linux/idr.h
+#include linux/err.h
+
+static ssize_t display_show_name(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct display_device *dsp = dev_get_drvdata(dev);
+ return snprintf(buf, PAGE_SIZE, %s\n, dsp-name);
+}
+
+static ssize_t display_show_type(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct display_device *dsp = dev_get_drvdata(dev);
+ return snprintf(buf, PAGE_SIZE, %s\n, dsp-type);
+}
+
+static ssize_t display_show_contrast(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct display_device *dsp = dev_get_drvdata(dev);
+ ssize_t rc = -ENXIO;
+
+ mutex_lock(dsp-lock);
+ if (likely(dsp-driver) dsp-driver-get_contrast)
+ rc = sprintf(buf, %d\n, dsp-driver-get_contrast(dsp));
+ mutex_unlock(dsp-lock);
+ return rc;
+}
+
+static ssize_t display_store_contrast(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct display_device *dsp = dev_get_drvdata(dev);
+ ssize_t ret = -EINVAL, size;
+ int contrast;
+ char *endp;
+
+ contrast = simple_strtoul(buf, endp, 0);
+ size = endp - buf;
+
+ if (*endp isspace(*endp))
+ size++;
+
+ if (size != count)
+ return ret;
+
+ mutex_lock(dsp-lock);
+ if (likely(dsp-driver dsp-driver-set_contrast)) {
+ pr_debug(display: set contrast to %d\n, contrast);
+ dsp-driver-set_contrast(dsp, contrast);
+ ret = count;
+ }
+ mutex_unlock(dsp-lock);
+ return ret;
+}
+
+static ssize_t display_show_max_contrast(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct display_device *dsp = dev_get_drvdata(dev);
+ ssize_t rc = -ENXIO;
+
+ mutex_lock(dsp-lock);
+ if (likely(dsp-driver))
+ rc = sprintf(buf, %d\n, dsp-driver-max_contrast);
+ mutex_unlock(dsp-lock);
+ return rc;
+}
+
+static struct device_attribute display_attrs[] = {
+ __ATTR(name, S_IRUGO, display_show_name, NULL),
+ __ATTR(type, S_IRUGO, display_show_type, NULL),
+ __ATTR(contrast, S_IRUGO | S_IWUSR, display_show_contrast,
display_store_contrast),
+ __ATTR(max_contrast, S_IRUGO, display_show_max_contrast, NULL),
+};
+
+static int display_suspend(struct device *dev, pm_message_t state)
+{
+ struct display_device *dsp = dev_get_drvdata(dev);
+
+ mutex_lock(dsp-lock);
+ if (likely(dsp-driver-suspend))
+ dsp-driver-suspend(dsp, state);
+ mutex_unlock(dsp-lock);
+ return 0;
+};
+
+static int display_resume(struct device *dev)
+{
+ struct display_device *dsp = dev_get_drvdata(dev);
+
+ mutex_lock(dsp-lock);
+ if (likely(dsp-driver-resume))
+ dsp-driver-resume(dsp);
+ mutex_unlock(dsp-lock);
+ return 0;
+};
+
+static struct mutex allocated_dsp_lock;
+static DEFINE_IDR(allocated_dsp);
+struct class *display_class;
+
+struct display_device *display_device_register(struct display_driver *driver,
+
2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
openSUSE 10.3 Alpha and KDE-3.5.6, xorg-x11-7.2. KDE is setup not to require a password to unlock, but it asks for password. When the screen unlocks, kwin is gone with no errors logged in /var/log/kdm or /var/log/messages. No problems with 2.6.20. Same problem on openSUSE 10.2 x86_64, KDE-3.5.5 and 2.6.21-rc2. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.20 SATA error
Ralf Müller wrote: I had the same type of problem using an unstable power supply - after replacing it the problems were gone ... Hm.. my shuttle box has only a 350W power supply, that could indeed be the problem, as I have an Athlon 64 X2 4400+ CPU (dual core), two SATA-II 500GB harddrives and a GeForce 7800GTX. Damn.. I thought I payed attention to the power supply when I bought the components for my computer :( tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] epoll reduced (to 1) number of passes over the ready set ...
On Wed, 28 Feb 2007, Eric Dumazet wrote: On Tuesday 27 February 2007 17:03, Davide Libenzi wrote: On Tue, 27 Feb 2007, Eric Dumazet wrote: On Tuesday 27 February 2007 03:32, Davide Libenzi wrote: Epoll is doing multiple passes over the ready set at the moment, because of the constraints over the f_op-poll() call. Looking at the code again, I noticed that we already hold the epoll semaphore in read, and this (together with other locking conditions that hold while doing an epoll_wait()) can lead to a smarter way to ship events to userspace (in a single pass). I added more (even) more comments to the code to explain the conditions why certain operations are safe. This is a stress application that can be used to test the new code. It spwans multiple thread and call epoll_wait() and epoll_ctl() from many threads. Stress tested on my dual Opteron 254 w/out any problems. Davide, This is really cool, because the size of epitem would fit now in 128 bytes instead of 192 (on x86_64 platforms). So we also reduce memory usage. Yeah, I forgot to mention that I removed the txlink member. I am pretty sure you can also remove revents member from epitem. It would greatly benefit to 32bits platforms, because resulting size would be 64 bytes instead of 68 (so a 50 % reduction because of 64 bytes alignment) Yes indee. That does not need to exist anymore, once the de-coupled loop is gone. Thx, I'll make a new patch later today. - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a bug in AS scheduler?
Jens Axboe wrote: On Wed, Feb 28 2007, Benoit Boissinot wrote: On 2/28/07, Jens Axboe [EMAIL PROTECTED] wrote: On Tue, Feb 27 2007, Xiaoning Ding wrote: Hi, I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c). In function as_close_req, variable delay is in millisecond, while ad-antic_expire is in jiffies. Doesn't the comparison of delay and ad-antic_expire make any problem? The related source code is quoted blow: if (ad-antic_status == ANTIC_OFF || !ad-ioc_finished) delay = 0; else delay = ((jiffies - ad-antic_start) * 1000) / HZ; antic_start is in jiffies, the difference is here multiplied by 1000 and divided by HZ to turn it into msecs. so delay is in msecs. I am pretty sure Xiaoning was talking about antic_expire, particularly this comparison: else if (delay = 20 delay = ad-antic_expire) Ah, I misread the name. That does look like a bug, antic_expire is in jiffies. You got it. Xiaoning - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
Mathiasen, Torben wrote: Assuming QE has 4 entries, I would expect CPM to be the same. But we need verification of that. If it needs 6, we are in more trouble. The QE can have up to 8, actually, but I'm willing to limit the driver to 4. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.21-rc1 and 2.6.21-rc2 kwin dies silently
On Wednesday 28 February 2007 17:19, Sid Boyce wrote: openSUSE 10.3 Alpha and KDE-3.5.6, xorg-x11-7.2. KDE is setup not to require a password to unlock, but it asks for password. When the screen unlocks, kwin is gone with no errors logged in /var/log/kdm or /var/log/messages. No problems with 2.6.20. Same problem on openSUSE 10.2 x86_64, KDE-3.5.5 and 2.6.21-rc2. Regards Sid. This is the linux kernel mailing list. Perhaps you should post your problem to the opensuse mailing list. 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 00/13] Syslets, Threadlets, generic AIO support, v3
Hi! If kernelspace rescheduling is that fast, then please explain me why userspace one always beats kernel/userspace? because 'user space scheduling' makes no sense? I explained my thinking about that in a past mail: ... 2) there has been an IO event. The thing is, for IO events we enter the kernel no matter what - and we'll do so for the next 10 years at ..actually, at some point 3D acceleration was done by accessing hw directly from userspace. OTOH I think we are moving away from that model, so it is probably irrelevant 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 00/13] Syslets, Threadlets, generic AIO support, v3
Hi! I think what you are not hearing, and what everyone else is saying (INCLUDING Linus), is that for most programmers, state machines are much, much harder to program, understand, and debug compared to multi-threaded code. You may disagree (were you a MacOS 9 programmer in another life?), and it may not even be true for you if you happen to be one of those folks more at home with Scheme continuations, for example. But it is true that for most kernel programmers, threaded programming is much easier to understand, and we need to engineer the kernel for what will be maintainable for the majority of the kernel development community. I understand that - and I totally agree. But when more complex, more bug-prone code results in higher performance - that must be used. We have linked lists and binary trees - the latter No-o. Kernel is not designed like that. Often, more complex and slightly faster code exists, and we simply use slower variant, because it is fast enough. 10% gain in speed is NOT worth major complexity increase. 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 00/13] Syslets, Threadlets, generic AIO support, v3
On Wed, 28 Feb 2007, Ingo Molnar wrote: * Davide Libenzi davidel@xmailserver.org wrote: Why can't aio_* be implemented with *simple* (or parallel/unrelated) syscall submit w/out the burden of a complex, limiting and heavy API there are so many variants of what people think 'asynchronous IO' should look like - i'd not like to limit them. I agree that once a particular syslet script becomes really popular, it might (and should) in fact be pushed into a separate system call. But i also agree that a one-shot-syscall sys_async() syscall could be done too - for those uses where only a single system call is needed and where the fetching of a single uatom would be small but nevertheless unnecessary overhead. A one-shot async syscall needs to get /8/ parameters (the syscall nr is the seventh parameter and the return code of the nested syscall is the eighth). So at least two parameters will have to be passed in indirectly and validated, and 32/64-bit compat conversions added, etc. anyway! At this point, given how threadlets can be easily/effectively dispatched from userspace, I'd argue the presence of either single/parallel or syslet submission altogether. Threadlets allows you to code chains *way* more naturally than syslets, and since they basically are like functions calls in the fast path, they can be used even for single/parallel submissions. No compat code required (ok, besides the trivial async_wait). My point is, the syslet infrastructure is expensive for the kernel in terms of compat, and extra code added to handle the cond/jumps/etc. Is also non-trivial to use from userspace. Are those big performance advantages there to justify its existence? I doubt that the price of a sysenter is a lot bigger than a atom decoding, but I'm looking forward in being proven wrong by real life performance numbers ;) - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
Kumar Gala wrote: Its your choice if you want to limit it to 4 or have it moved into a different minor range. I can live with both. I'd rather we support 8 now. Ok, a different minor range it is, then. 192-199? -- Timur Tabi Linux Kernel Developer @ Freescale - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.21-rc1 and 2.6.21-rc2 kwin dies silently
/ openSUSE 10.3 Alpha and KDE-3.5.6, xorg-x11-7.2. KDE is setup not to/ / require a password to unlock, but it asks for password. When the screen/ / unlocks, kwin is gone with no errors logged in /var/log/kdm or/ / /var/log/messages. No problems with 2.6.20./ / Same problem on openSUSE 10.2 x86_64, KDE-3.5.5 and 2.6.21-rc2./ / Regards/ / Sid./ This is the linux kernel mailing list. Perhaps you should post your problem to the opensuse mailing list. Regards That's very much appreciated. The point is that all vanilla kernels up to 2.6.20+ have not had the problems now seen on 2.6.20-rc1 and 2.6.20-rc2 and like other problems reported, sic framebuffer, etc., there is a distinct likelihood that it's related to those kernels and worth reporting here where it will also be seen by the openSUSE kernel developers. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
H. Peter Anvin wrote: It sounds like the QE driver should be moved to a separate minor range, and given 8 minors. I just had a thought - since udev doesn't care about major/minor number assignments, can we say that the limit is 4 devices if you're not using udev, and 8 otherwise? -- Timur Tabi Linux Kernel Developer @ Freescale - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wanted: simple, safe x86 stack overflow detection
I guess most stack corruptions touch only a small part of the stack. These kinds of corruptions can only be detected from inside the program. Anyway, going beyond the program's stack boundaries would fault the program. Checking the threadinfo constantly it'll be (IMHO) mostly useless... On 2/28/07, Chuck Ebbert [EMAIL PROTECTED] wrote: Can we just put a canary in the threadinfo and check it on every task switch? What are the drawbacks? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- - Thiago Galesi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc2 radeon backlight
the backlight on my thinkpad still (2.6.20 worked fine) doesn't come on if i have the radeon backlight enabled. without it, i guess it's the ibm acpi modules that controls the backlight and it seems to work fine. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
Timur Tabi wrote: H. Peter Anvin wrote: It sounds like the QE driver should be moved to a separate minor range, and given 8 minors. I just had a thought - since udev doesn't care about major/minor number assignments, can we say that the limit is 4 devices if you're not using udev, and 8 otherwise? That seems pretty silly. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Using serio_register_driver
On 2/27/07, Fausto Carvalho [EMAIL PROTECTED] wrote: Well, i have a 8042 controller connected to the keyboard controller that send information about battery and others to the keyboard interrupt and io ports in the format of keystrokes. I want a way to not alter atkbd but to create another driver that lives together with atkbd. Is there a way? Depending on how big and box-specific the code is we could either add it to i8042 or you need to imaplement a pass-through serio port in your driver. You would filter out interesting bytes and pass the rest to the new serio port that your driver shoudl register. Tnen atkbd would bind to that new port and function as usual. The only problem is that you woudl need to bind you driver to the keyboard port from userspace (via sysfs - /sys/bus/devices/serioX/drvctl) -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc2
Yes. I goofed, and missed that stupid case. The offending lines should just die. Patch already sent to Linus. Could the patch be posted? or could I see a git commit so I can get it myself? Thanks, David Brown - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 00/13] Syslets, Threadlets, generic AIO support, v3
On Wed, 28 Feb 2007, Davide Libenzi wrote: At this point, given how threadlets can be easily/effectively dispatched from userspace, I'd argue the presence of either single/parallel or syslet submission altogether. Threadlets allows you to code chains *way* more naturally than syslets, and since they basically are like functions calls in the fast path, they can be used even for single/parallel submissions. Well, I agree, except for one thing: - user space execution is *inherently* more expensive. Why? Stack. Stack. Stack. If you support threadlets with user space code, it means that you need a separate user-space stack for each threadlet. That's a potentially *big* cost to bear, both from a setup standpoint and from simply a memory allocation standpoint. Quite frankly, I think threadlets are a great idea, but I think the lack of user-level footprint is *also* a great idea, and you should support both. In short - the only thing I *don't* think is a great idea are those linked lists of atoms. I still think it's a pretty horrible interface, and I still don't think it really buys us very much. The only way it would buy us a lot is to change the linked lists dynamically (ie add new events at the end while old events are still executing), but quite frankly, that just makes the whole interface *even*worse* and just makes me have debugging nightmares (I'm also not even convinced it really would help us: we might avoid some costs of adding new events, but it would only avoid them for serial execution, and if the whole point of this is to execute things in parallel, that's a stupid thing to do). So I would repeat my call for getting rid of the atoms, and instead just do a single submission at a time. Do the linking by running a threadlet that has user space code (and the stack overhead), which is MUCH more flexible. And do nonlinked single system calls without *either* atoms *or* a user-space stack footprint. Please? What am I missing? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 2.6.20 1/1] fbdev, mm: hecuba/E-Ink fbdev driver
I'm not sure I understand. What the current implementation does is to use host based framebuffer memory. Apps mmap that memory and draw to that. Then after the delay, that framebuffer is written to the device's memory. That's the scenario for hecubafb where the Apollo controller maintains it's own internal framebuffer. When you say without the framebuffer, if you meant without the host memory, then this method doesn't work. If you mean without the device's internal memory, then yes, I think we can do that, because it would be up to the driver to use the touched pagelist to then perform IO as suitable for its device. I meant for it to work for non framebuffer devices. I realized that not such a great idea. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: First desktop motherboard supported by LinuxBIOS: GIGABYTE M57SLI-S4
Quick question. Can this board initialize more than one graphics card? On Wed, 21 Feb 2007, Brandon Howard wrote: Oops, forgot to include the relevant links in the previous email: [1] http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2287 [2] http://www.newegg.com/Product/Product.asp?Item=N82E16813128014 [3] http://linuxbios.org/Download_LinuxBIOS [4] http://www.fsf.org/campaigns/free-bios.html --- Brandon Howard [EMAIL PROTECTED] wrote: Hi, The GIGABYTE M57SLI-S4 [1] is the first-ever desktop motherboard supported by a Free Open Source BIOS, thanks to AMD engineer Yinghai Lu who released GPL-licensed code last month. This state-of-the-art motherboard is based on the NVIDIA nForce 570 SLI chipset and AMD's latest Socket AM2. It contains tons of advanced features such as: Support for AMD Athlon 64 X2, Athlon 64 FX and Athlon 64 processors 2X PCI Express x16 slots 3X PCI Express x1 slots 2X PCI slots 3X 1394a (FireWire) ports 10X USB 2.0 16GB maximum memory SATA RAID 6X SATA 3Gb/s slots. This motherboard can be obtained today from many retail and online stores [2] and the source code for the BIOS can be downloaded from the LinuxBIOS SVN server [3]. This is a huge victory in the quest for a completely Free Open Source general-purpose computer that enables users to have full control over their own hardware. The Free Software Foundation has made the campaign for a Free BIOS a top priority because it is a key component in the software stack of personal computers [4]. The need for a Free BIOS is even more pressing since DRM and Treacherous Computing have found their way into some proprietary BIOSes and EFI. From a practical perspective, LinuxBIOS removes the need for ugly hacks and workarounds in the kernel that compensate for buggy BIOSes we can now fix the BIOS ourselves. I encourage everyone upgrading their desktop computers to consider getting this motherboard or another one that is supported by LinuxBIOS. -Brandon Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 00/13] Syslets, Threadlets, generic AIO support, v3
Michael K. Edwards wrote: State machines are much harder to write without going through a real on-paper design phase first. But multi-threaded code is much harder for a team of average working coders to write correctly, judging from the numerous train wrecks that I've been called in to salvage over the last ten years or so. I have to agree; state machines are harder to design and read, but multithreaded programs are harder to write and debug _correctly_. Another way of putting it is that the threadlet approach is easier to do, but harder to do _right_. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] fbdev driver for S3 Trio/Virge, updated
On Thu, 2007-02-22 at 00:53 +, James Simmons wrote:
+/* image data is MSB-first, fb structure is MSB-first too */
+static inline u32 expand_color(u32 c)
+{
+ return ((c 1) | ((c 2) 7) | ((c 4) 14) | ((c 8)
21)) * 0xFF;
+}
+
+/* s3fb_iplan_imageblit silently assumes that almost everything is
8-pixel aligned */
Hmn, same thing with vga16fb... Perhaps we should bring back the
fontwidth flag of 2.2 and 2.4 kernels.
Ug no. It is possible to get 12,6 bit width fonts working with vga
interleaved planes. I got it paritally working but never got back to it.
Its in my queue of this to do. Now that I finished the display class I
need to get around to makeing drm/fbdev work together :-)
Of course, not fontwidth exactly, but to allow the driver to specify the
alignment of the blit engine, in this case 8 pixels. I do believe X also
has similar functionality to compensate for the limitation of the
hardware.
Isn't scan_align in pixmap for this? Or do we need more.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/1] PXAFB: Support for backlight control
On Thu, Feb 22, 2007 at 12:33:35PM +0200, Paul Sokolovsky wrote: We in handhelds.org codebase have attached patch* to make corgi_bl more suitable for general use. This patch was submitted to Richard (so, more votes needed ;-) ). Otherwise, snippet I pasted is from real machine implementation, HP iPaq h4000. You have my vote! :) So let me suggest this patch who allows multiple driver instances (I use it for both LCD and keypad backlighti devices). Hope it could be merged into main line (maybe without the corgi prefix ;-). Nice patch. I have no problem with it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] no backlight on radeon after recent kernel upgrades
So the problem is not the configuration but that for some reason the backlight state is set to off by default. On Thu, 22 Feb 2007, David Miller wrote: From: James Simmons [EMAIL PROTECTED] Date: Thu, 22 Feb 2007 15:55:24 + (GMT) I just tested various confirations of backlight support. Backlight is ALWAYS selected by default when you select a particular fbdev driver that has backlight support. You just have the option to turn it off if you want. These problems are showing up because of stale .config files. BTW, enabling the backlight option broke things for me with Radeon on sparc64 too, FWIW. And when the option was presented to me for the first time, the default was yes, so that's what I gave it. This is what a lot of users would see. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 00/13] Syslets, Threadlets, generic AIO support, v3
On 2/28/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote: 130 lines skipped... Yeah, I edited it down a lot before sending it. :-) I have only one question - wasn't it too lazy to write all that? :) I'm pretty lazy all right. But occasionally an interesting problem (and revamping AIO is very interesting) makes me think, and what little thinking I do is always accompanied by writing. Once I've thought something through to the point that I think I understand the problem, I've even been known to attempt a solution. Not always, though; more often, I find a new interesting problem, or else I am forcibly reminded that I should be spending my little store of insight on revenue-producing activity. In this instance, there didn't seem to be any harm in sending my thoughts to LKML as I wrote them, on the off chance that Ingo or Davide would get some value out of them in this design cycle (which any code I eventually get around to producing will miss). So far, I've gotten some rather dismissive pushback from Ingo and Alan (who seem to have no interest outside x86 and less understanding than I would have thought of what real userspace code looks like), a why preach to people who know more than you do from Davide, a brief aside on the dominance of x86 from Oleg, and one off-list keep up the good work. Not a very rich harvest from (IMHO) pretty good seeds. In short, so far the Linux kernel community is upholding its reputation for insularity, arrogance, coding without prior design, lack of interest in userspace problems, and inability to learn from the mistakes of others. (None of these characterizations depends on there being any real insight in anything I have written.) Linus himself has a very different reputation -- plenty of arrogance all right, but genuine brilliance and hard work, and sincere (if cranky) efforts to explain the theory of operations underlying central design choices. So far he hasn't commented directly on anything I have had to say; it will be interesting to see whether he tells me to stop annoying the pros and to go away until I have some code to contribute. Happy hacking, - Michael P. S. I do think threadlets are brilliant, though, and reading Ingo's patches gave me a much better idea of what would be involved in prototyping Asynchronously Executed I/O Unit opcodes. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ecryptfs: check xattr operation support fix
- ecryptfs_write_inode_size_to_metadata() error code was ignored.
- i_op-setxattr() must be supported by lower fs because used below.
Signed-off-by: Monakhov Dmitriy [EMAIL PROTECTED]
---
fs/ecryptfs/inode.c |6 +++---
fs/ecryptfs/mmap.c |3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index 27fd14a..9ccefad 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -168,9 +168,9 @@ static int grow_file(struct dentry *ecryptfs_dentry, struct
file *lower_file,
goto out;
}
i_size_write(inode, 0);
- ecryptfs_write_inode_size_to_metadata(lower_file, lower_inode, inode,
- ecryptfs_dentry,
- ECRYPTFS_LOWER_I_MUTEX_NOT_HELD);
+ rc = ecryptfs_write_inode_size_to_metadata(lower_file, lower_inode,
+ inode, ecryptfs_dentry,
+ ECRYPTFS_LOWER_I_MUTEX_NOT_HELD);
ecryptfs_inode_to_private(inode)-crypt_stat.flags |= ECRYPTFS_NEW_FILE;
out:
return rc;
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 1e5d2ba..416985f 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -491,7 +491,8 @@ static int ecryptfs_write_inode_size_to_xattr(struct inode
*lower_inode,
goto out;
}
lower_dentry = ecryptfs_dentry_to_lower(ecryptfs_dentry);
- if (!lower_dentry-d_inode-i_op-getxattr) {
+ if (!lower_dentry-d_inode-i_op-getxattr ||
+ !lower_dentry-d_inode-i_op-setxattr) {
printk(KERN_WARNING
No support for setting xattr in lower filesystem\n);
rc = -ENOSYS;
--
1.5.0.1
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] HID and USB HID update for 2.6.21-rc2
On Wed, 28 Feb 2007, Jiri Kosina wrote: The diffstat looks larger because the usbhid code is moved from USB-specific directory to HID-specific directory No. The diffstat looks huge because you moved hid_blacklist into a header file, and that is a big enough change that git won't consider the rename to be just a rename any more (you basically moved the old usbdrivers/usb/input/hid-core.c file into *two* files: hid-core.c and usbhid.h). Why do that? It now gets included INTO EVERY DAMN FILE that includes usbhid.h, since that one now has that static const struct hid_blacklist definition in it. Yet *nothing* wants it, except for the one C file that it used to be in. No way in hell will I include this kind of crap without major explanations for why the crap is not crap. And quite frankly, I don't think such explanations exist. I'm also not going to pull it if you just add a new commit to undo the idiocy. That thing needs to be totally re-done, as far as I'm concerned. I don't want to touch anything that has EVER even *seen* anything that stupid. Yes, I'm grumpy. I don't like big changes at this stage, and if they are also STUPID big changes, as this seems to be, I refuse to pull them entirely. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc2
On Wed, 28 Feb 2007 08:44:45 -0800 David Brown wrote: Yes. I goofed, and missed that stupid case. The offending lines should just die. Patch already sent to Linus. Could the patch be posted? or could I see a git commit so I can get it myself? I'm attaching it below. It hit the git commits mailing list just a few minutes ago. --- ~Randy When removing set_native_irq I missed the fact that it was called in a couple of places that were compiled even when SMP support is disabled. And since the irq_desc[].affinity field only exists in SMP things broke. Thanks to Simon Arlott [EMAIL PROTECTED] for spotting this. There are a couple of ways to fix this but the simplest one is to just remove the assignments. The affinity field is only used to display a value to the user, and nothing on either i386 or x86_64 reads it or depends on it being any particlua value, so skipping the assignment is safe. The assignment that is being removed is just for the initial affinity value before the user explicitly sets it. The irq_desc array initializes this field to CPU_MASK_ALL so the field is initialized to a reasonable value in the SMP case without being set. Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] --- arch/i386/kernel/io_apic.c |2 -- arch/x86_64/kernel/io_apic.c |4 2 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c index 6fec4da..e4408ff 100644 --- a/arch/i386/kernel/io_apic.c +++ b/arch/i386/kernel/io_apic.c @@ -1354,7 +1354,6 @@ static void __init setup_IO_APIC_irqs(void) } spin_lock_irqsave(ioapic_lock, flags); __ioapic_write_entry(apic, pin, entry); - irq_desc[irq].affinity = TARGET_CPUS; spin_unlock_irqrestore(ioapic_lock, flags); } } @@ -2875,7 +2874,6 @@ int io_apic_set_pci_routing (int ioapic, int pin, int irq, int edge_level, int a spin_lock_irqsave(ioapic_lock, flags); __ioapic_write_entry(ioapic, pin, entry); - irq_desc[irq].affinity = TARGET_CPUS; spin_unlock_irqrestore(ioapic_lock, flags); return 0; diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c index 48593f6..0a91368 100644 --- a/arch/x86_64/kernel/io_apic.c +++ b/arch/x86_64/kernel/io_apic.c @@ -830,10 +830,6 @@ static void setup_IO_APIC_irq(int apic, int pin, unsigned int irq, disable_8259A_irq(irq); ioapic_write_entry(apic, pin, entry); - - spin_lock_irqsave(ioapic_lock, flags); - irq_desc[irq].affinity = TARGET_CPUS; - spin_unlock_irqrestore(ioapic_lock, flags); } static void __init setup_IO_APIC_irqs(void) -- 1.5.0.g53756 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.20 SATA error
On Wed, 28 Feb 2007 07:40:23 -0500 (EST) Gerhard Mack [EMAIL PROTECTED] wrote: hello, Can someone tell me what this means? ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/100 I am fairly certain this is a bug in the 2.6.20 kernel. I never see it in 2.6.19*, just 2.6.20. It is some kind of but in the SATA code paths, or at least that's all it appears to affect on my system. What chipset do you have? I have an nforce4 chipset. In another thread, I think they were saying it was either a SATA chipset driver bug, or a problem in libata core. -- shannon | governorrhea: | a contagious disease that spreads from | the governor of a state downward through other | offices and his corporate sponsors - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] HID and USB HID update for 2.6.21-rc2
On Wed, 28 Feb 2007, Linus Torvalds wrote: The diffstat looks larger because the usbhid code is moved from USB-specific directory to HID-specific directory No. The diffstat looks huge because you moved hid_blacklist into a header file, and that is a big enough change that git won't consider the rename to be just a rename any more (you basically moved the old usbdrivers/usb/input/hid-core.c file into *two* files: hid-core.c and usbhid.h). Yes, but was done by two separate commits, diffstat -M for 3d5af52d0997d545995d8747c8057be5dee49b14 shows hid-core.c as a 100% rename, but later commit b41ea57c01a1943ab36af0017cfc1329815af9ce splits it, so in cummulative diffstat it doesn't show it as a rename. Why do that? It now gets included INTO EVERY DAMN FILE that includes usbhid.h, since that one now has that static const struct hid_blacklist definition in it. Yet *nothing* wants it, except for the one C file that it used to be in. You're right that usbhid.h is not a best place for it. The thing is that hid_blacklist[] and related things just badly needs cleanup - it has been for quite a long time placed on a really random place in the middle of a .c file. In addition to that, the corresponding #defines are scatthered around, interleaved with functions (see for example where USB_VENDOR_ID_PANJIT and USB_VENDOR_ID_TURBOX defines are). I'm also not going to pull it if you just add a new commit to undo the idiocy. That thing needs to be totally re-done, as far as I'm concerned. I don't want to touch anything that has EVER even *seen* anything that stupid. This IMHO just needs cleanup. Will you accept creating a separate header file solely for purposes of this blacklist and related defines? Otherwise I will just drop this cleanup, but I still think that the current situation is horrible. Yes, I'm grumpy. I don't like big changes at this stage, and if they are also STUPID big changes, as this seems to be, I refuse to pull them entirely. Are you also opposed to just the code movement? There are some bugfixes I think that really need merging, so just to know what would be acceptable for you at the time being. Thanks, -- 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] affinity is not defined in non-smp kernels - i386
Eric W. Biederman wrote: Fernando Luis Vázquez Cao [EMAIL PROTECTED] writes: Initialize affinity only when building SMP kernels. Reasonable. I goofed here. However I would prefer my patch that just deletes these problem lines. These lines don't really contribute anything and are harmless to remove. Where is the initialization performed, then? -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] HID and USB HID update for 2.6.21-rc2
On Wed, 28 Feb 2007, Jiri Kosina wrote: You're right that usbhid.h is not a best place for it. Not the best place for it is the understatement of the year. It's totally idiotic. This IMHO just needs cleanup. Will you accept creating a separate header file solely for purposes of this blacklist and related defines? *NO*. Dammit, we don't put static initializers in header files. We don't duplicate the data in every single thing that includes a header file. If you want to duplicate the data, you export it as a real data structure, and you *still* put the data structure in a .c file. Otherwise I will just drop this cleanup, but I still think that the current situation is horrible. WHAT CLEANUP? The thing is the anti-thesis of a cleanup. There is no excuse for putting a large array in a header file and including it millions of times. Or even just twice. The point of a header file is to *declare* things, not to have big data structures in. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, Threadlets, generic AIO support, v3
* Linus Torvalds [EMAIL PROTECTED] wrote: [...] The only way it would buy us a lot is to change the linked lists dynamically (ie add new events at the end while old events are still executing), [...] that's quite close to what Jens' FIO plugin for syslets (engines/syslet-rw.c) does currently: it builds lists of syslets as IO gets submitted, batches them up for some time and then sends them off. It is a natural next step to do this for in-flight syslets as well. 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/
fix implicit declaration in nv_backlight.
drivers/video/nvidia/nv_backlight.c: In function 'nvidia_bl_init': drivers/video/nvidia/nv_backlight.c:103: error: implicit declaration of function 'pmac_has_backlight_type' Signed-off-by: Dave Jones [EMAIL PROTECTED] --- linux-2.6.20.noarch/drivers/video/nvidia/nv_backlight.c~2007-02-20 22:25:15.0 -0500 +++ linux-2.6.20.noarch/drivers/video/nvidia/nv_backlight.c 2007-02-20 22:25:31.0 -0500 @@ -12,6 +12,9 @@ #include linux/backlight.h #include linux/fb.h #include linux/pci.h +#ifdef __powerpc__ +#include asm/backlight.h +#endif #include nv_local.h #include nv_type.h #include nv_proto.h -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with freezable workqueues
On Wednesday, 28 February 2007 14:17, Srivatsa Vaddagiri wrote: On Wed, Feb 28, 2007 at 12:11:03PM +0100, Rafael J. Wysocki wrote: In addition to thawing worker thread before kthread_stopping it, there are minor changes required in worker threads, to check for is_cpu_offline(bind_cpu) when they come out of refrigerator and jump to wait_to_die if so (ex: softirq.c). I guess you would need these changes before freezer-based hotplug is merged, in which case Gautham can send those patches out first. Yes, please, if that's possible. After looking at the current workqueue code, the above minor change I suggested is not required. So you should be able to fix your kthread_stop on a frozen worker thread hangs problem by just a simple patch like this (against 2.6.20-mm2): --- workqueue.c.org 2007-02-28 18:32:48.0 +0530 +++ workqueue.c 2007-02-28 18:44:23.0 +0530 @@ -718,6 +718,8 @@ static void cleanup_workqueue_thread(str insert_wq_barrier(cwq, barr, 1); cwq-should_stop = 1; alive = 1; + if (frozen(cwq-thread)) + thaw(cwq-thread); } spin_unlock_irq(cwq-lock); Can you test with this? Sure, I will. Note that as Oleg commented, freezable workqueues are broken w/o his patch here: http://marc.theaimsgroup.com/?l=linux-kernelm=116855740612755 So you need to have Andrew/Linux pick up the above patch first to have correctly functioning freezable workqueues. This one already is in -mm. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with freezable workqueues
On Wednesday, 28 February 2007 14:27, Srivatsa Vaddagiri wrote: On Wed, Feb 28, 2007 at 06:47:21PM +0530, Srivatsa Vaddagiri wrote: --- workqueue.c.org 2007-02-28 18:32:48.0 +0530 +++ workqueue.c 2007-02-28 18:44:23.0 +0530 @@ -718,6 +718,8 @@ static void cleanup_workqueue_thread(str insert_wq_barrier(cwq, barr, 1); cwq-should_stop = 1; alive = 1; + if (frozen(cwq-thread)) + thaw(cwq-thread); I meant thaw_process(cwq-thread) I thought so, but thanks anyway. ;-) } spin_unlock_irq(cwq-lock); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] HID and USB HID update for 2.6.21-rc2
On Wed, 28 Feb 2007, Linus Torvalds wrote: There is no excuse for putting a large array in a header file and including it millions of times. Or even just twice. The point of a header file is to *declare* things, not to have big data structures in. The point was that noone else than hid/hid-core.c would ever be going to include this header with blacklist. The blacklist is growing in time quite rapidly and having it in the middle of the code just didn't look pretty - currently you have to perform some scrolling effort just to skip from usbhid_init_reports() to hid_find_max_report(), which just looks very sad to me. But OK, I will leave it in there. -- 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: [RFC] killing the NR_IRQS arrays.
Benjamin Herrenschmidt [EMAIL PROTECTED] writes: What I really object to is not the irq numbers. As an arbitrary number does not impose limits. What I object to is drivers that can't handle the full range of numbers, and the limits imposed upon those numbers when you require them to be indexes into an array. For talking to user space I expect we will have numbers for a long time to come yet. I wouldn't bother too much about going into bus specific bits like irq_request(dev, ...). Well, actually, I _do_ think it's a good thing to pass the struct device to irq_request but that's a different issue completely. Well irq_request is probably a bit late for associating an irq with a struct device. And I don't see how to get the device name from that but making that association wouldn't be a bad thing. I think bus types should provide bus specific helpers to obtain the struct irq *'s for a given device on that bus, but the API for requesting/freeing them shall remain generic. Yes. But if you can do a good job of wrapping them so a driver wouldn't need to care at all that could help simplify drivers and remove one more tidbit of complexity from drivers. However for a widespread change. The less you have to think about it the more quickly you can get it completed. So I would rather do several wide spread changes in succession, that I don't have to think about much to do (i.e. the change mostly meets the obviously correct requirement). Then to do one single change that I have to think about harder to accomplish. The more thinking comes into the picture the more you open yourself up to breaking something by accident because it wasn't clear how the code should be changed, and the more it slows down the conversion. Conversions where we have had to think about things are notoriously slow to complete. Even if they are a good thing to do. The examples I can think of are the kthread API and the DMA api. Last I checked there were still a few drivers in the kernel using virt_to_bus... I don't really get the benefits I'm after unless the conversion can actually be completed for everything. So the more I have to think about any one piece the less I intend to do it. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] killing the NR_IRQS arrays.
Arnd Bergmann [EMAIL PROTECTED] writes:
I have to admit I still don't really understand how this works
at all. Can a driver that uses msi-x have different handlers
for each of those interrupts registered simultaneously?
Yes, and the irqs can be routed at different cpus independently.
However not all hardware supports all 4K irqs. 4K is the implementation
defined maximu. Although infiniband HCA's are rumored to support a
lot of irqs and it isn't uncommon for simpler nics to support 4 or so.
Conceptually think of it as having an irq controller embedded in your
pci device.
The MSI messages are writes to special addresses that are then
converted into CPU interrupts.
I would expect that instead there should be only one 'struct irq'
for the device, with the handler getting a 12 bit number argument.
No. That would be unnecessary coalescing. Even if that was what the
hardware layer gave us the (and it doesn't) the generic layers should
demux these things as much as is reasonable.
s390: got rid of irq numbers already
Yes. I should really look at that more and see if I could bring
s390 into the generic irq code with my planned changes.
I don't think there is much point in changing the s390 code, but
the way it is solved there may be interesting for other buses
as well. The interrupt handler there is not being registered
explicitly, but is part of the driver (in case of subchannel)
or of the device (in case of ccw_device) data structure.
Similarly, in a pci device, one could imagine that the
struct pci_driver contains a irq_handler_t member that
is registered from the pci_device_probe() function
if present.
Yes. There is some potential there. Although we would have to go
through an extra hoop to make it a pci specific handler type.
Note that we can even start converting device drivers first, before
moving away from irq numbers. A typical PCI driver should get
somewhat simpler by the conversion, and when they are all converted,
we can replace pci_dev-irq with a struct irq* under the covers.
Reasonable if it is easy and straight forward.
Something like pci_request_irq(dev,) and the helper looks at
dev-irq under the covers and calls request_irq or whatever makes
sense. Is this what you are thinking. Examples would help me here.
Ok, I had an example in on of my previous posts, but based on the
discussion since then, it has become significantly simpler, basically
reducing the work to
struct irq *pci_irq_request(struct pci_device *dev,
irq_handler_t handler)
{
if (!dev-irq)
return -ENODEV;
return irq_request(irq, handler, IRQF_SHARED,
dev-driver-name, dev);
}
int pci_irq_free(struct pci_device *dev)
{
return irq_free(dev-irq, dev);
}
The most significant change of this to the current code
would be that we can pass arguments down to irq_request
automatically, e.g. the irq handler can always get the
pci_device as its dev_id.
Yes. Mostly. Since dev_id is what is passed back to the irq handler,
it makes sense to pass the device when the irq is registered.
Passing the driver a pointer to the driver specific structure (not
the pci device) make a lot more of sense from an efficiency
standpoint. Now it may make sense to remove the irq parameter
from irq_handler_t, and require drivers to look at their dev_id to
see which irq they really are processing.
There is a danger here of making things so generic you don't have good
performance, or the code becomes unnecessarily complex.
For talking to user space I expect we will have numbers for a long time
to come yet.
I was wondering about that. Do you only mean /proc/interrupts or
are there other user interfaces we need to worry about?
Yes. There are other interfaces like /proc/irq/XXX/smp_affinity,
for irq migration. There are also device specific ioctls. There is
lspci. I don't know what all else, and given the current state of the
kernel it is hard to grep for.
For /proc/interrupts, what could break if we have interrupt numbers
only local to each controller and potentially duplicate numbers
in the list? It's good to be paranoid about changes to proc files,
but I can definitely see value in having meaningful interrupt
numbers in there instead of making up a more or less random mapping
to a flat number space.
Well I can have meaning full flat numbers and on i386 and x86_64
except for msi I have that. The problem is that for the numbers
to have meaning I get a very sparse usage of the numbers, because
very frequently the hardware interrupt controllers has pins that
are not connected up, so I have about an order of magnitude more
numbers then I have actually irqs in use. That is before I start
reserving irq numbers for MSI.
For MSI (since they cannot be shared) it would actually make a lot of
sense to make the numbers domain,bus,device,func,(Nth device irq) but
I can't because
[RFC][PATCH] intel8x0: revert regression that broke sounds after S3 suspend
The regression in 2.6.19-rc3 (namely 30b35399ceb2398d05837863476dcb12f12f3a82, [ALSA] Various fixes for suspend/resume of ALSA PCI drivers), broke HP nw8000 speaker sounds after S3 suspend (headphones still worked). Removing this line makes the sounds work again... Signed-off-by: Tommi Kyntola [EMAIL PROTECTED] --- This is a FYI kinda message, which Rafael Wysocki asekd me to send, and something that is clearly not the correct way to go with this, but I was unable to locate the actual reason for the regression and this does fix it for me, so here it goes. Wether other devices suffer from this or not, I don't know. I was only able test this on an HP nw8000, which has the said intel8x0. I'll gladly try out further patches or submit configs, or whatever more verbose information is asked for. Kynde diff --git a/sound/pci/intel8x0.c b/sound/pci/intel8x0.c index a289abf..f62a456 100644 --- a/sound/pci/intel8x0.c +++ b/sound/pci/intel8x0.c @@ -2470,7 +2470,6 @@ static int intel8x0_suspend(struct pci_dev *pci, pm_message_t state) } pci_disable_device(pci); pci_save_state(pci); - pci_set_power_state(pci, pci_choose_state(pci, state)); return 0; } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0 ... - 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 + 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 If CPM0 is 46, then CPM5 is not 47, but not 49 either. Unless it's not CPM5 but CPM3? Honestly, I don't know. I was just correcting the obvious typo (47 instead of 49). It's obvious it shouldn't be 47, but it's not obvious it should be 49 instead. I'll try to get an answer from someone, but I'm no CPM expert. Adding linuxppc-embedded to the CC:, someone there surely knows. Segher - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][RFC] ext3: Handle ext[34]_journal_stop() failure
Where are many places where _journal_stop() return code wasn't
checked. Off cause _journal_stop() failed very rarely (and usually
with fatal consequences), but this does'n meen it should not be checked.
For example most retry loops looks like follows:
ext3_journal_stop(handle);
if (err == -ENOSPC ext3_should_retry_alloc(dir-i_sb, retries))
goto retry;
It is realy insane do retry if ext3_journal_stop() has failed, because
this may increase damage in case of real problem.
Signed-off-by: Monakhov Dmitriy [EMAIL PROTECTED]
---
fs/ext3/acl.c | 12
fs/ext3/inode.c | 22 +-
fs/ext3/ioctl.c | 12
fs/ext3/namei.c | 48
fs/ext3/xattr.c |4 ++--
fs/ext4/acl.c | 12
fs/ext4/inode.c | 22 +-
fs/ext4/ioctl.c | 12
fs/ext4/namei.c | 48
fs/ext4/xattr.c |4 ++--
10 files changed, 134 insertions(+), 62 deletions(-)
diff --git a/fs/ext3/acl.c b/fs/ext3/acl.c
index 1e5038d..bbf4d8a 100644
--- a/fs/ext3/acl.c
+++ b/fs/ext3/acl.c
@@ -375,7 +375,7 @@ int
ext3_acl_chmod(struct inode *inode)
{
struct posix_acl *acl, *clone;
-int error;
+ int error, error2;
if (S_ISLNK(inode-i_mode))
return -EOPNOTSUPP;
@@ -402,7 +402,9 @@ ext3_acl_chmod(struct inode *inode)
goto out;
}
error = ext3_set_acl(handle, inode, ACL_TYPE_ACCESS, clone);
- ext3_journal_stop(handle);
+ error2 = ext3_journal_stop(handle);
+ if (error2 (!error || error == -ENOSPC))
+ error = error2;
if (error == -ENOSPC
ext3_should_retry_alloc(inode-i_sb, retries))
goto retry;
@@ -485,7 +487,7 @@ ext3_xattr_set_acl(struct inode *inode, int type, const
void *value,
{
handle_t *handle;
struct posix_acl *acl;
- int error, retries = 0;
+ int error, error2, retries = 0;
if (!test_opt(inode-i_sb, POSIX_ACL))
return -EOPNOTSUPP;
@@ -509,7 +511,9 @@ retry:
if (IS_ERR(handle))
return PTR_ERR(handle);
error = ext3_set_acl(handle, inode, type, acl);
- ext3_journal_stop(handle);
+ error2 = ext3_journal_stop(handle);
+ if (error2 (!error || error == -ENOSPC))
+ error = error2;
if (error == -ENOSPC ext3_should_retry_alloc(inode-i_sb, retries))
goto retry;
diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
index 816f0c5..68d1c71 100644
--- a/fs/ext3/inode.c
+++ b/fs/ext3/inode.c
@@ -962,7 +962,9 @@ static int ext3_get_block(struct inode *inode, sector_t
iblock,
* Huge direct-io writes can hold off commits for long
* periods of time. Let this commit run.
*/
- ext3_journal_stop(handle);
+ ret = ext3_journal_stop(handle);
+ if (ret)
+ goto get_block;
handle = ext3_journal_start(inode, DIO_CREDITS);
if (IS_ERR(handle))
ret = PTR_ERR(handle);
@@ -2998,7 +3000,13 @@ int ext3_setattr(struct dentry *dentry, struct iattr
*attr)
if (attr-ia_valid ATTR_GID)
inode-i_gid = attr-ia_gid;
error = ext3_mark_inode_dirty(handle, inode);
- ext3_journal_stop(handle);
+ if (error) {
+ ext3_journal_stop(handle);
+ goto err_out;
+ }
+ error = ext3_journal_stop(handle);
+ if (error)
+ goto err_out;
}
if (S_ISREG(inode-i_mode)
@@ -3016,7 +3024,9 @@ int ext3_setattr(struct dentry *dentry, struct iattr
*attr)
rc = ext3_mark_inode_dirty(handle, inode);
if (!error)
error = rc;
- ext3_journal_stop(handle);
+ rc = ext3_journal_stop(handle);
+ if (!error)
+ error = rc;
}
rc = inode_setattr(inode, attr);
@@ -3231,7 +3241,7 @@ int ext3_change_inode_journal_flag(struct inode *inode,
int val)
{
journal_t *journal;
handle_t *handle;
- int err;
+ int err, err2;
/*
* We have to be very careful here: changing a data block's
@@ -3274,7 +3284,9 @@ int ext3_change_inode_journal_flag(struct inode *inode,
int val)
err = ext3_mark_inode_dirty(handle, inode);
handle-h_sync = 1;
- ext3_journal_stop(handle);
+ err2 = ext3_journal_stop(handle);
+ if (!err)
+ err = err2;
ext3_std_error(inode-i_sb, err);
return err;
diff --git a/fs/ext3/ioctl.c b/fs/ext3/ioctl.c
index
Re: [PATCH 2.6.20] kobject net ifindex + rename
Hi, Patch for 2.6.20 is attached. ... and in the meantime netdevices aren't class_device any more :) IOW, your patch isn't going to work any more. Also, I think wireless could benefit from this as well. The kobject framework is well designed, so adding these features is trivial change and won't run the risk of breaking anything (famous last words). Obviously, hotplug apps are free to ignore those additional features. Why not just add this to base kobject_rename instead? That way, userspace is notified for all renames in sysfs. The patch then collapses down to the change in net's sysfs code to add the ifindex to the environment, and another change in kobject to invoke a new event when a name changes and show the old name. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/2] ehea: NAPI multi queue TX/RX path for SMP
Hi,
+static inline int ehea_hash_skb(struct sk_buff *skb, int num_qps)
+{
+ u32 tmp;
+ if ((skb-nh.iph-protocol == IPPROTO_TCP)
+skb-protocol == ETH_P_IP) {
skb-protocol has network byte order. The ETH_P_IP test should also
logically come before checking the IP protocol.
fixed.
+ tmp = (skb-h.th-source + (skb-h.th-dest 16)) % 31;
Only locally generated packets have a valid h.th pointer.
good point. I'll fix that.
I'll send a new patch set later today
Thanks,
Jan-Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] kobject net ifindex + rename
On 28-02-2007 02:27, Jean Tourrilhes wrote:
Hi all,
...
Patch for 2.6.20 is attached. The patch was tested on a system
running the hotplug scripts, and on another system running udev.
Have fun...
Jean
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]
-
...
diff -u -p linux/net/core/net-sysfs.j1.c linux/net/core/net-sysfs.c
--- linux/net/core/net-sysfs.j1.c 2007-02-27 15:01:08.0 -0800
+++ linux/net/core/net-sysfs.c2007-02-27 15:06:49.0 -0800
@@ -412,6 +412,17 @@ static int netdev_uevent(struct class_de
if ((size = 0) || (i = num_envp))
return -ENOMEM;
+ /* pass ifindex to uevent.
+ * ifindex is useful as it won't change (interface name may change)
+ * and is what RtNetlink uses natively. */
+ envp[i++] = buf;
+ n = snprintf(buf, size, IFINDEX=%d, dev-ifindex) + 1;
+ buf += n;
+ size -= n;
+
+ if ((size = 0) || (i = num_envp))
Btw.:
1. if size == 10 and snprintf returns 9 (without NULL)
then n == 10 (with NULL), so isn't it enough (here and above):
if ((size 0) || (i = num_envp))
2. shouldn't there be (here and above):
envp[--i] = NULL;
+ return -ENOMEM;
+
envp[i] = NULL;
return 0;
}
...
diff -u -p linux/drivers/base/class.j1.c linux/drivers/base/class.c
--- linux/drivers/base/class.j1.c 2007-02-26 18:38:10.0 -0800
+++ linux/drivers/base/class.c2007-02-27 15:52:37.0 -0800
@@ -841,6 +841,8 @@ int class_device_rename(struct class_dev
{
int error = 0;
char *old_class_name = NULL, *new_class_name = NULL;
+ char *devname_string = NULL;
+ char *envp[2];
class_dev = class_device_get(class_dev);
if (!class_dev)
@@ -849,6 +851,15 @@ int class_device_rename(struct class_dev
pr_debug(CLASS: renaming '%s' to '%s'\n, class_dev-class_id,
new_name);
+ devname_string = kmalloc(strlen(class_dev-class_id) + 15, GFP_KERNEL);
+ if (!devname_string) {
+ class_device_put(class_dev);
+ return -ENOMEM;
+ }
+ sprintf(devname_string, INTERFACE_OLD=%s, class_dev-class_id);
+ envp[0] = devname_string;
+ envp[1] = NULL;
+
#ifdef CONFIG_SYSFS_DEPRECATED
if (class_dev-dev)
old_class_name = make_class_name(class_dev-class-name,
@@ -868,8 +879,16 @@ int class_device_rename(struct class_dev
sysfs_remove_link(class_dev-dev-kobj, old_class_name);
}
#endif
+
+ /* This function is only used for network interface.
+ * Some hotplug package track interfaces by their name and
+ * therefore want to know when the name is changed by the user. */
+ if(!error)
+ kobject_uevent_env(class_dev-kobj, KOBJ_RENAME, envp);
+
class_device_put(class_dev);
+ kfree(devname_string);
Maybe I miss something, but it seems kobject_uevent_env copies
pointers from envp instead of buffers' contents.
Regards,
Jarek P.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] kobject net ifindex + rename
On Wed, Feb 28, 2007 at 10:34:37AM +0100, Jarek Poplawski wrote: On 28-02-2007 02:27, Jean Tourrilhes wrote: ... + /* This function is only used for network interface. +* Some hotplug package track interfaces by their name and +* therefore want to know when the name is changed by the user. */ + if(!error) + kobject_uevent_env(class_dev-kobj, KOBJ_RENAME, envp); + class_device_put(class_dev); + kfree(devname_string); Maybe I miss something, but it seems kobject_uevent_env copies pointers from envp instead of buffers' contents. And it's enough - sorry. Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] kobject net ifindex + rename
On Tue, Feb 27, 2007 at 05:27:41PM -0800, Jean Tourrilhes wrote: diff -u -p linux/drivers/base/class.j1.c linux/drivers/base/class.c --- linux/drivers/base/class.j1.c 2007-02-26 18:38:10.0 -0800 +++ linux/drivers/base/class.c2007-02-27 15:52:37.0 -0800 @@ -841,6 +841,8 @@ int class_device_rename(struct class_dev This function is not in the 2.6.21-rc2 kernel, so you might want to rework this patch a bit :) Also, it's userspace that causes the rename to happen, so it knows it did it, why should the kernel have to emit a message to tell userspace again what just happened? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] ehea: dynamic port SMP support
Hi, this version has the issues fixed which were mentioned by Patrick McHardy. The patch set includes two patches against linux-2.6.21-rc1: - dynamic add / remove port: Interface has been discussed and approved by John Rose (see: http://www.spinics.net/lists/netdev/msg25327.html) - NAPI multi queue TX/RX path for SMP: Integrated comments from mailing list (R. Dreier) As soon as discussions about splitting NAPI from netdevice have settled and this functionality is in kernel, we'll provide a patch for the new interface. (see: http://www.spinics.net/lists/netdev/msg25647.html) please apply. Jan-Bernd Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ehea: dynamic add / remove port
This patch introduces functionality to dynamically add / remove
ehea ports via an userspace DLPAR tool. It creates a subnode for
each logical port in the sysfs.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 42295d6..e595d6b 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@ #include asm/abs_addr.h
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0046
+#define DRV_VERSIONEHEA_0048
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -380,10 +380,11 @@ struct ehea_port_res {
};
+#define EHEA_MAX_PORTS 16
struct ehea_adapter {
u64 handle;
- u8 num_ports;
- struct ehea_port *port[16];
+ struct ibmebus_dev *ebus_dev;
+ struct ehea_port *port[EHEA_MAX_PORTS];
struct ehea_eq *neq; /* notification event queue */
struct workqueue_struct *ehea_wq;
struct tasklet_struct neq_tasklet;
@@ -406,7 +407,7 @@ struct ehea_port {
struct net_device *netdev;
struct net_device_stats stats;
struct ehea_port_res port_res[EHEA_MAX_PORT_RES];
- struct device_node *of_dev_node; /* Open Firmware Device Node */
+ struct of_device ofdev; /* Open Firmware Device */
struct ehea_mc_list *mc_list;/* Multicast MAC addresses */
struct vlan_group *vgrp;
struct ehea_eq *qp_eq;
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 1ef3846..42edd8d 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -580,7 +580,7 @@ static struct ehea_port *ehea_get_port(s
{
int i;
- for (i = 0; i adapter-num_ports; i++)
+ for (i = 0; i EHEA_MAX_PORTS; i++)
if (adapter-port[i])
if (adapter-port[i]-logical_port_id == logical_port)
return adapter-port[i];
@@ -2274,8 +2274,6 @@ static void ehea_tx_watchdog(struct net_
int ehea_sense_adapter_attr(struct ehea_adapter *adapter)
{
struct hcp_query_ehea *cb;
- struct device_node *lhea_dn = NULL;
- struct device_node *eth_dn = NULL;
u64 hret;
int ret;
@@ -2292,18 +2290,6 @@ int ehea_sense_adapter_attr(struct ehea_
goto out_herr;
}
- /* Determine the number of available logical ports
-* by counting the child nodes of the lhea OFDT entry
-*/
- adapter-num_ports = 0;
- lhea_dn = of_find_node_by_name(lhea_dn, lhea);
- do {
- eth_dn = of_get_next_child(lhea_dn, eth_dn);
- if (eth_dn)
- adapter-num_ports++;
- } while ( eth_dn );
- of_node_put(lhea_dn);
-
adapter-max_mc_mac = cb-max_mc_mac - 1;
ret = 0;
@@ -2313,79 +2299,150 @@ out:
return ret;
}
-static int ehea_setup_single_port(struct ehea_port *port,
- struct device_node *dn)
+int ehea_get_jumboframe_status(struct ehea_port *port, int *jumbo)
{
- int ret;
- u64 hret;
- struct net_device *dev = port-netdev;
- struct ehea_adapter *adapter = port-adapter;
struct hcp_ehea_port_cb4 *cb4;
- u32 *dn_log_port_id;
- int jumbo = 0;
-
- sema_init(port-port_lock, 1);
- port-state = EHEA_PORT_DOWN;
- port-sig_comp_iv = sq_entries / 10;
-
- if (!dn) {
- ehea_error(bad device node: dn=%p, dn);
- ret = -EINVAL;
- goto out;
- }
-
- port-of_dev_node = dn;
-
- /* Determine logical port id */
- dn_log_port_id = (u32*)get_property(dn, ibm,hea-port-no, NULL);
-
- if (!dn_log_port_id) {
- ehea_error(bad device node: dn_log_port_id=%p,
- dn_log_port_id);
- ret = -EINVAL;
- goto out;
- }
- port-logical_port_id = *dn_log_port_id;
-
- port-mc_list = kzalloc(sizeof(struct ehea_mc_list), GFP_KERNEL);
- if (!port-mc_list) {
- ret = -ENOMEM;
- goto out;
- }
-
- INIT_LIST_HEAD(port-mc_list-list);
+ u64 hret;
+ int ret = 0;
- ret = ehea_sense_port_attr(port);
- if (ret)
- goto out;
+ *jumbo = 0;
- /* Enable Jumbo frames */
+ /* (Try to) enable *jumbo frames */
cb4 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb4) {
ehea_error(no mem for cb4);
+ ret = -ENOMEM;
+ goto out;
} else {
- hret = ehea_h_query_ehea_port(adapter-handle,
+ hret = ehea_h_query_ehea_port(port-adapter-handle,
port-logical_port_id,
H_PORT_CB4,
H_PORT_CB4_JUMBO, cb4);
-
[PATCH 2/2] ehea: NAPI multi queue TX/RX path for SMP
This patch provides a functionality that allows parallel
RX processing on multiple RX queues by using dummy netdevices.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff -Nurp -X dontdiff linux-2.6.21-rc1/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.21-rc1/drivers/net/ehea/ehea.h2007-02-28 18:20:06.0
+0100
+++ patched_kernel/drivers/net/ehea/ehea.h 2007-02-28 18:21:23.0
+0100
@@ -39,7 +39,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0048
+#define DRV_VERSIONEHEA_0052
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -78,8 +78,6 @@
#define EHEA_RQ2_PKT_SIZE 1522
#define EHEA_L_PKT_SIZE 256/* low latency */
-#define EHEA_POLL_MAX_RWQE 1000
-
/* Send completion signaling */
#define EHEA_SIG_IV_LONG 1
@@ -357,8 +355,8 @@ struct ehea_port_res {
struct ehea_qp *qp;
struct ehea_cq *send_cq;
struct ehea_cq *recv_cq;
- struct ehea_eq *send_eq;
- struct ehea_eq *recv_eq;
+ struct ehea_eq *eq;
+ struct net_device *d_netdev;
spinlock_t send_lock;
struct ehea_q_skb_arr rq1_skba;
struct ehea_q_skb_arr rq2_skba;
@@ -372,7 +370,6 @@ struct ehea_port_res {
int swqe_count;
u32 swqe_id_counter;
u64 tx_packets;
- struct tasklet_struct send_comp_task;
spinlock_t recv_lock;
struct port_state p_state;
u64 rx_packets;
@@ -416,7 +413,9 @@ struct ehea_port {
char int_aff_name[EHEA_IRQ_NAME_SIZE];
int allmulti;/* Indicates IFF_ALLMULTI state */
int promisc; /* Indicates IFF_PROMISC state */
+ int num_tx_qps;
int num_add_tx_qps;
+ int num_mcs;
int resets;
u64 mac_addr;
u32 logical_port_id;
diff -Nurp -X dontdiff linux-2.6.21-rc1/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.21-rc1/drivers/net/ehea/ehea_main.c 2007-02-28
18:20:06.0 +0100
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2007-02-28 18:21:29.0
+0100
@@ -51,13 +51,18 @@ static int rq1_entries = EHEA_DEF_ENTRIE
static int rq2_entries = EHEA_DEF_ENTRIES_RQ2;
static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
static int sq_entries = EHEA_DEF_ENTRIES_SQ;
+static int use_mcs = 0;
+static int num_tx_qps = EHEA_NUM_TX_QP;
module_param(msg_level, int, 0);
module_param(rq1_entries, int, 0);
module_param(rq2_entries, int, 0);
module_param(rq3_entries, int, 0);
module_param(sq_entries, int, 0);
+module_param(use_mcs, int, 0);
+module_param(num_tx_qps, int, 0);
+MODULE_PARM_DESC(num_tx_qps, Number of TX-QPS);
MODULE_PARM_DESC(msg_level, msg_level);
MODULE_PARM_DESC(rq3_entries, Number of entries for Receive Queue 3
[2^x - 1], x = [6..14]. Default =
@@ -71,6 +76,7 @@ MODULE_PARM_DESC(rq1_entries, Number of
MODULE_PARM_DESC(sq_entries, Number of entries for the Send Queue
[2^x - 1], x = [6..14]. Default =
__MODULE_STRING(EHEA_DEF_ENTRIES_SQ) ));
+MODULE_PARM_DESC(use_mcs, 0:NAPI, 1:Multiple receive queues, Default = 1 );
void ehea_dump(void *adr, int len, char *msg) {
int x;
@@ -197,7 +203,7 @@ static int ehea_refill_rq_def(struct ehe
struct sk_buff *skb = netdev_alloc_skb(dev, packet_size);
if (!skb) {
ehea_error(%s: no mem for skb/%d wqes filled,
- dev-name, i);
+ pr-port-netdev-name, i);
q_skba-os_skbs = fill_wqes - i;
ret = -ENOMEM;
break;
@@ -345,10 +351,11 @@ static int ehea_treat_poll_error(struct
return 0;
}
-static int ehea_poll(struct net_device *dev, int *budget)
+static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
+ struct ehea_port_res *pr,
+ int *budget)
{
- struct ehea_port *port = netdev_priv(dev);
- struct ehea_port_res *pr = port-port_res[0];
+ struct ehea_port *port = pr-port;
struct ehea_qp *qp = pr-qp;
struct ehea_cqe *cqe;
struct sk_buff *skb;
@@ -359,14 +366,12 @@ static int ehea_poll(struct net_device *
int skb_arr_rq2_len = pr-rq2_skba.len;
int skb_arr_rq3_len = pr-rq3_skba.len;
int processed, processed_rq1, processed_rq2, processed_rq3;
- int wqe_index, last_wqe_index, rq, intreq, my_quota, port_reset;
+ int wqe_index, last_wqe_index, rq, my_quota, port_reset;
processed = processed_rq1 = processed_rq2 = processed_rq3 = 0;
last_wqe_index = 0;
my_quota = min(*budget, dev-quota);
- my_quota = min(my_quota, EHEA_POLL_MAX_RWQE);
- /* rq0 is low latency RQ */
Re: PROBLEM: BUG: when resuming from suspend-to-ram
On Wednesday, 28 February 2007 01:27, Kristian Grønfeldt Sørensen wrote:
On Tue, 2007-02-27 at 23:30 +0100, Rafael J. Wysocki wrote:
On Tuesday, 27 February 2007 23:04, Rafael J. Wysocki wrote:
Hi,
On Tuesday, 27 February 2007 19:45, Kristian Grønfeldt Sørensen wrote:
Hi.
PROBLEM: BUG: when resumimg from suspend-to-ram
My laptop have a problem with resuming from suspend-to-ram.
It does not occur every time - most of the time, resume works without
any problem.at all.
After it occurs, the laptop refuses to go into suspend-to-ram mode until
next reboot.
What do you mean by refuses? Are there any suspicious messages in
dmesg?
The system is a Debian unstable running with a self-compiled 2.6.20
kernel downloaded from kernel.org.
I've only tried suspend-to-ram on 2.6.20 so I don't know whether or not
other versions might have the same problem.
I'm not subscribed to the list. Please CC me.
I guess one of the drivers you use goes awry at some point. Please
provide
us with more information (like dmesg output after a failing resume).
I'm sorry, I've just been told you sent it. :-)
CLASS: Unregistering class device. ID = 'event3'
class_uevent - name = event3
class_device_create_uevent called for event3
device class 'event3': release.
class_device_create_release called for event3
BUG: unable to handle kernel paging request at virtual address 6b6b6b6b
printing eip:
f8825a81
*pde =
Oops: [#1]
PREEMPT
Modules linked in: tg3 battery ac thermal fan button i915 drm binfmt_misc
rfcomm l2cap ipv6 fuse capability commoncap cpufreq_performance aoe
af_packet nls_utf8 ntfs nls_iso8859_1 nls_cp437 vfat fat dm_snapshot
dm_mirror dm_mod ieee80211_cr ypt_tkip ieee80211_crypt pd6729
snd_seq_dummy
snd_seq_oss snd_seq_midi snd_rawmi di snd_seq_midi_event snd_seq
snd_seq_device sermouse hci_vhci hci_uart wbsd mmc _block mmc_core tun msr
cpuid cpufreq_stats container video speedstep_lib speeds tep_centrino
processor sr_mod sbp2 scsi_mod ide_cd cdrom eth1394 hci_usb bluetoo th
pcmcia firmware_class irda snd_intel8x0m snd_intel8x0 snd_ac97_codec
crc_ccit t ac97_bus snd_pcm_oss snd_mixer_oss rtc i2c_i801 snd_pcm
snd_timer ohci1394 iee e1394 i2c_core serio_raw intel_agp iTCO_wdt snd
soundcore snd_page_alloc ehci_hc d pcspkr uhci_hcd yenta_socket
rsrc_nonstatic pcmcia_core usbcore agpgart moused ev evdev
CPU:0
EIP:0060:[f8825a81]Not tainted VLI
EFLAGS: 00010202 (2.6.20-x300 #1)
EIP is at evdev_disconnect+0xb1/0xe0 [evdev]
This points us to a suspect. Can you please run gdb vmlinux against the
vmlinux in your kernel sources directory and then
gdb l *evdev_disconnect+0xb1
OK. Recopiled the kernel with CONFIG_DEBUG_INFO=y
This gives:
(gdb) l *evdev_disconnect+0xb1
No symbol evdev_disconnect in current context.
I guess you meant gdb drivers/input/evdev.ko
Yes, exactly.
This gives:
(gdb) l *evdev_disconnect+0xb1
0xa81 is in evdev_disconnect (include/asm/processor.h:716).
711However we don't do prefetches for pre XP Athlons currently
712That should be fixed. */
713 #define ARCH_HAS_PREFETCH
714 static inline void prefetch(const void *x)
715 {
716 alternative_input(ASM_NOP4,
717 prefetchnta (%1),
718 X86_FEATURE_XMM,
719 r (x));
720 }
Hm, interesting. Looks like a pointer points to nowhere in
input_unregister_device(), but I don't know which one. This may be
an evdev problem ...
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Current PATA working tree
Alan wrote: While Andrew and -mm are taking a bit of a break... I've uploaded a patch file of the libata PATA working tree versus 2.6.20-mm2 to http://zeniv.linux.org.uk/~alan/IDE Generated without --show-c-function. Sigh. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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]Support for Marvell 7042 Chip
Added Support for Marvell 7042 Chip - 7042 has same
capabilities behavior as 6042.
Patch based upon stable Linux 2.6.20.1 Kernel Tree...
Signed-off-by: Thomas A. Morrison [EMAIL PROTECTED]
--- drivers/ata/sata_mv.c.orig 2007-02-20 01:34:32.0 -0500
+++ drivers/ata/sata_mv.c 2007-02-28 10:22:03.0 -0500
@@ -546,6 +546,9 @@ static const struct pci_device_id mv_pci
{ PCI_VDEVICE(TTI, 0x2310), chip_7042 },
+ /* add Marvell 7042 support */
+ { PCI_VDEVICE(MARVELL, 0x7042), chip_7042 },
+
{ } /* terminate list */
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: null pointer dereference in cfq_dispatch_requests (2.6.21-rc2 and 2.6.20)
I can reliably reproduce a null pointer dereference on 2.6.20 and 2.6.21-rc2. I will keep digging to find the kernel version where this last worked, but wanted to see if there were any immediate experiments I should try. The failure is caused by running tiobench on a MD raid6 array with 6 out of 8 disks available. The commands I issued to reproduce this are: mdadm -A /dev/md0 /dev/sd[bcdefg] mount /dev/md0 /mnt/raid tiobench --numruns 5 --size 2048 --dir /mnt/raid The filesystem is ext3. The controller is an LSI 1068. Here are the two BUG messages first 2.6.21-rc2 followed by 2.6.20. I will reply to this message with the config. Fedora Core release 5 (Bordeaux) Kernel 2.6.21-rc2 on an i686 [ 431.709022] BUG: unable to handle kernel NULL pointer dereference at virtual address 005c [ 431.717993] printing eip: [ 431.720825] c01e1e00 [ 431.723112] *pde = 32e70001 [ 431.726065] Oops: [#1] [ 431.728997] SMP [ 431.730922] Modules linked in: raid456 xor nfsd exportfs lockd nfs_acl sunrpc autofs4 hidp l2cap bluetooth iptable_raw xt_policy xt_multiport ipt_ULOG ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_SAME ipt_REJECT ipt_REDIRECT ipt_recent ipt_owner ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_iprange ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype xt_tcpmss xt_pkttype xt_physdev xt_NFQUEUE xt_MARK xt_mark xt_mac xt_limit xt_length xt_helper xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables x_tables video sbs i2c_ec dock button battery asus_acpi ac radeon drm ipv6 lp parport_pc parport floppy uhci_hcd ehci_hcd e1000 i2c_i801 sg mptsas mptscsih mptbase i2c_core scsi_transport_sas pcspkr dm_snapshot dm_zero dm_mirror dm_mod ata_piix ata_generic libata sd_mod scsi_mod ext3 jbd [ 431.812682] CPU:0 [ 431.812682] EIP:0060:[c01e1e00]Not tainted VLI [ 431.812683] EFLAGS: 00010002 (2.6.21-rc2 #4) [ 431.825386] EIP is at cfq_dispatch_insert+0xb/0x53 [ 431.830413] eax: f6c96ec0 ebx: ecx: c0410568 edx: [ 431.837608] esi: f7e956a4 edi: ebp: f6c96cc0 esp: c0491e54 [ 431.844760] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [ 431.850847] Process swapper (pid: 0, ti=c0491000 task=c03ff4c0 task.ti=c0447000) [ 431.858360] Stack: f76ae3bc f6c96cc0 f6c96cc0 c01e1fc9 00e7 [ 431.867165]c03ffa10 c0143123 0004 c03ff4c0 f7e957ac [ 431.875998]f7e956a4 f7e956a4 f7d39000 f7e956a4 c01d8767 0001 0046 [ 431.884656] Call Trace: [ 431.887396] [c01e1fc9] cfq_dispatch_requests+0x138/0x3f0 [ 431.893274] [c0143123] __lock_acquire+0xb64/0xbf4 [ 431.898513] [c01d8767] elv_next_request+0x1a1/0x1b1 [ 431.903923] [f8a26621] scsi_request_fn+0x59/0x336 [scsi_mod] [ 431.910148] [c01dbb20] blk_run_queue+0x37/0x63 [ 431.915100] [f8a25561] scsi_next_command+0x25/0x2f [scsi_mod] [ 431.921330] [f8a2571f] scsi_end_request+0x9e/0xa8 [scsi_mod] [ 431.927493] [f8a258c0] scsi_io_completion+0x15a/0x32b [scsi_mod] [ 431.934113] [f882c5fb] sd_rw_intr+0x21b/0x245 [sd_mod] [ 431.939787] [c031b23a] _spin_unlock_irqrestore+0x3e/0x4d [ 431.945640] [f8a213f6] scsi_finish_command+0x84/0x8b [scsi_mod] [ 431.952051] [c0142166] trace_hardirqs_on+0x116/0x158 [ 431.957446] [c012e181] __do_softirq+0x5a/0xe9 [ 431.962329] [c01dc291] blk_done_softirq+0x68/0x73 [ 431.967447] [c012e199] __do_softirq+0x72/0xe9 [ 431.972290] [c0107033] do_softirq+0x6f/0xec [ 431.976888] [c031b0ce] _spin_unlock_irq+0x20/0x2c [ 431.982064] [c0318b1b] __sched_text_start+0x96b/0x9f3 [ 431.987574] [c01553a1] handle_fasteoi_irq+0x0/0xab [ 431.992823] [c010716d] do_IRQ+0xbd/0xd4 [ 431.997061] [c0105886] common_interrupt+0x2e/0x34 [ 432.002301] [c0103240] mwait_idle_with_hints+0x3b/0x3f [ 432.007931] [c01033b9] cpu_idle+0xb5/0xce [ 432.012368] [c044ca9a] start_kernel+0x4a5/0x4ad [ 432.017398] [c044c1b8] unknown_bootoption+0x0/0x202 [ 432.022829] === [ 432.026511] Code: 1f e9 3b c0 c7 04 24 51 6d 3a c0 e8 43 83 f4 ff e8 77 46 f2 ff ff 4f 34 83 c4 18 5b 5e 5f 5d c3 55 57 56 89 c6 53 8b 40 0c 89 d3 8b 7a 5c 8b 68 04 89 d0 e8 b5 fe ff ff 8b 43 14 89 da 25 01 80 [ 432.046781] EIP: [c01e1e00] cfq_dispatch_insert+0xb/0x53 SS:ESP 0068:c0491e54 [ 432.054403] Kernel panic - not syncing: Fatal exception in interrupt [ 432.060912] BUG: at arch/i386/kernel/smp.c:546 smp_call_function() [ 432.067203] [c0118c63] smp_call_function+0x64/0xd0 [ 432.072473] [c023df9a] do_unblank_screen+0x25/0x11b [ 432.077910] [c0118cea] smp_send_stop+0x1b/0x40 [ 432.082848] [c01296cb] panic+0x54/0xfd [ 432.087033] [c010639c] die+0x202/0x236 [ 432.091222] [c031cc58] do_page_fault+0x507/0x5e0 [ 432.096323] [c01716e2] kmem_cache_free+0xa1/0xb2 [ 432.101353] [c01716e2] kmem_cache_free+0xa1/0xb2 [ 432.106415]
Re: Problem with freezable workqueues
On Wed, Feb 28, 2007 at 12:36:52AM +0100, Johannes Berg wrote: On Wed, 2007-02-28 at 02:28 +0300, Oleg Nesterov wrote: Ugh. I know nothing, nothing, nothing about suspend. I'll try to guess. Commit: ed746e3b18f4df18afa3763155972c5835f284c5 Yes? with the patch above, _cpu_down() called _after_ freeze_processes() ??? perfect :) See also my original mail and the thread: http://thread.gmane.org/gmane.linux.power-management.general/4314 How about other kthread_stop()s ? For example, kernel/softirq.c:cpu_callback() ? I'd they should be affected as well. For me, I guess I haven't run into them because xfs is enough to freeze the box ;) As for Rafael, I don't know why he isn't seeing that... I haven't been able to test this patch on my quad powermac so far unfortunately, been sick and away from the machine. I'll probably be able to test tomorrow. They will be affected. In our first implemetentation of general cpu_down after freeze(http://lkml.org/lkml/2007/2/14/107) we had a new state known CPU_DEAD_KILL_THREADS, the notifications for which were being sent *after* we thawed the processes in __cpu_down. However, in the version which we are working on, we are thawing processes individually in CPU_DEAD before cleaning/stopping them. I haven't observed any bad lockups/freeze chills with this approach. But I need to test it a bit more before posting them. regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 on shutdown in nf_ct_iterate_cleanup()
Chuck Ebbert wrote:
Patrick McHardy wrote:
This patch is against current stable-2.6.20, it applies
cleanly to 2.6.20 as well.
Everything works OK, but I get:
BUG: warning: (!list_empty(unconfirmed)) at
net/netfilter/nf_conntrack_core.c:1068/nf_ct_cleanup()
nf_ct_cleanup+0x66/0x122 [nf_conntrack]
kill_l4proto+0x0 [nf_conntrack]
nf_conntrack_l4proto_unregister+0x7d/0x82 [nf_conntrack]
nf_conntrack_l3proto_ipv4_fini+0x3c/0x46 [nf_conntrack_ipv4]
sys_delete_module+0x18a/0x1b1
Thanks, the previous approach doesn't seem to work properly without
unpleasant event cache hacks. This patch takes a simpler approach
and keeps the unconfirmed list iteration, but makes sure to make
forward progress.
[NETFILTER]: conntrack: fix {nf,ip}_ct_iterate_cleanup endless loops
Fix {nf,ip}_ct_iterate_cleanup unconfirmed list handling:
- unconfirmed entries can not be killed manually, they are removed on
confirmation or final destruction of the conntrack entry, which means
we might iterate forever without making forward progress.
This can happen in combination with the conntrack event cache, which
holds a reference to the conntrack entry, which is only released when
the packet makes it all the way through the stack or a different
packet is handled.
- taking references to an unconfirmed entry and using it outside the
locked section doesn't work, the list entries are not refcounted and
another CPU might already be waiting to destroy the entry
What the code really wants to do is make sure the references of the hash
table to the selected conntrack entries are released, so they will be
destroyed once all references from skbs and the event cache are dropped.
Since unconfirmed entries haven't even entered the hash yet, simply mark
them as dying and skip confirmation based on that.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 841de8621862a5406d2a236dd142a5e5db167d25
tree 347d137f0d6466f0b4da83256bfbeaa4150f105a
parent 8d1117a9f5d302d8d460fbe7ef322b382e45c9ce
author Patrick McHardy [EMAIL PROTECTED] Mon, 26 Feb 2007 18:48:05 +0100
committer Patrick McHardy [EMAIL PROTECTED] Wed, 28 Feb 2007 19:02:00 +0100
include/linux/netfilter_ipv4/ip_conntrack_core.h |2 +-
include/net/netfilter/nf_conntrack_core.h|2 +-
net/ipv4/netfilter/ip_conntrack_core.c |2 +-
net/netfilter/nf_conntrack_core.c|2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/netfilter_ipv4/ip_conntrack_core.h
b/include/linux/netfilter_ipv4/ip_conntrack_core.h
index 907d4f5..e3a6df0 100644
--- a/include/linux/netfilter_ipv4/ip_conntrack_core.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack_core.h
@@ -45,7 +45,7 @@ static inline int ip_conntrack_confirm(s
int ret = NF_ACCEPT;
if (ct) {
- if (!is_confirmed(ct))
+ if (!is_confirmed(ct) !is_dying(ct))
ret = __ip_conntrack_confirm(pskb);
ip_ct_deliver_cached_events(ct);
}
diff --git a/include/net/netfilter/nf_conntrack_core.h
b/include/net/netfilter/nf_conntrack_core.h
index 7fdc72c..85634e1 100644
--- a/include/net/netfilter/nf_conntrack_core.h
+++ b/include/net/netfilter/nf_conntrack_core.h
@@ -64,7 +64,7 @@ static inline int nf_conntrack_confirm(s
int ret = NF_ACCEPT;
if (ct) {
- if (!nf_ct_is_confirmed(ct))
+ if (!nf_ct_is_confirmed(ct) !nf_ct_is_dying(ct))
ret = __nf_conntrack_confirm(pskb);
nf_ct_deliver_cached_events(ct);
}
diff --git a/net/ipv4/netfilter/ip_conntrack_core.c
b/net/ipv4/netfilter/ip_conntrack_core.c
index 8556a4f..f8b3009 100644
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -1242,7 +1242,7 @@ get_next_corpse(int (*iter)(struct ip_co
list_for_each_entry(h, unconfirmed, list) {
ct = tuplehash_to_ctrack(h);
if (iter(ct, data))
- goto found;
+ set_bit(IPS_DYING_BIT, ct-status);
}
write_unlock_bh(ip_conntrack_lock);
return NULL;
diff --git a/net/netfilter/nf_conntrack_core.c
b/net/netfilter/nf_conntrack_core.c
index 9b02ec4..cb29ba7 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1052,7 +1052,7 @@ get_next_corpse(int (*iter)(struct nf_co
list_for_each_entry(h, unconfirmed, list) {
ct = nf_ct_tuplehash_to_ctrack(h);
if (iter(ct, data))
- goto found;
+ set_bit(IPS_DYING_BIT, ct-status);
}
write_unlock_bh(nf_conntrack_lock);
return NULL;
