2 ports could not bond to a aggregator in 802.3ad mode issue
I wish to be personally CC'ed the answers/comments posted to the list in response to my posting. I have 2 ports(eth0, eth1) in my device. I use kernel(2.6.23) bonding driver v3.1.3 (June 13, 2007) to bond 2 ports to one aggregator and use the following commands to setup the environment: insmod ./bonding.ko mode=4 miimon=100 ifconfig bond0 172.23.26.223 netmask 255.255.255.0 ifconfig eth0 down ifconfig eth1 down ifenslave bond0 eth0 eth1 After the setting, I cat the proc entry and got the following information Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer2 (0) MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 802.3ad info LACP rate: slow Active Aggregator Info: Aggregator ID: 1 Number of ports: 1 Actor Key: 17 Partner Key: 1 Partner Mac Address: 00:00:00:00:00:00 Slave Interface: eth0 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:e0:0c:48:00:04 Aggregator ID: 1 Slave Interface: eth1 MII Status: up Link Failure Count: 0 Permanent HW addr: 6f:74:66:73:74:79 Aggregator ID: 2 It shows that 2 ports could not bond to a aggregator. After I trace the the bonding driver code, I modify the ad_port_selection_logic() in bond_3ad.c as following: - ((MAC_ADDRESS_COMPARE(&(port->partner_oper_system), &(null_mac_addr)) && // partner answers + (!(MAC_ADDRESS_COMPARE(&(port->partner_oper_system), &(null_mac_addr)) && // partner answers !aggregator->is_individual) // but is not individual OR ) After the modification, I cat the proc entry again and the result is as following: /home/shares # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007) Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer2 (0) MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 802.3ad info LACP rate: slow Active Aggregator Info: Aggregator ID: 1 Number of ports: 2 Actor Key: 17 Partner Key: 1 Partner Mac Address: 00:00:00:00:00:00 Slave Interface: eth0 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:e0:0c:48:00:04 Aggregator ID: 1 Slave Interface: eth1 MII Status: up Link Failure Count: 0 Permanent HW addr: 6f:74:66:73:74:79 Aggregator ID: 1 The behavior changes from 'one aggregator with one port' to 'one aggregator with 2 ports', the latter seems more accurate. Is there a bug in bonding driver code v3.1.3 (June 13, 2007)? Best regards, Lewis Li -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
volanoMark 24% regression in 2.6.24-rc6: why a simple patch makes it
With kernel 2.6.24-rc6, volanoMark has much regression. 1) On 8-core stoakley: 17%; 2) On 16-core tigerton: 24%. I bisected it down to patch fbdcf18df73758b2e187ab94678b30cd5f6ff9f9. It is to fix the bad cpu number in /proc/cpuinfo. As a matter of fact, this issue is already fixed by other 2 patches: 699d934d5f958d7944d195c03c334f28cc0b3669 and c0c52d28e05e8bdaa2126570c02ecb1a7358cecc. At the first glance, the patch looks good, at least no conflict with the other 2 patches. After double-checking it, I found in below call chain: smp_store_cpu_info => identify_cpu => init_intel => init_intel_cacheinfo. When CONFIG_X86_HT=y, init_intel_cacheinfo will uses cpuinfo_x86->cpu_index, which is initiated by smp_store_cpu_info. If with patch fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, cpuinfo_x86->cpu_index is initiated after identify_cpu is called, so init_intel_cacheinfo just always initiates per_cpu(cpu_llc_id, 0) = l2_id or l3_id. Then, set_cpu_sibling_map will set bad llc_shared_map, so the core domain won't be built. By checking domain info from dmesg, it really confirms my consequence. >From this case, I really found that core domain could improve performance, at >least when testing by volanoMark. :) The solution is just to revert patch fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, because other 2 patches which fixed the same issue are already in 2.6.24-rc5. -yanmin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HSM violation errors
I'm seeing errors in dmesg and the like. It appears to be somewhat similar to the issue reported here: http://kerneltrap.org/mailarchive/linux-kernel/2007/8/25/164711 except that my machine doesn't freeze, and everything seems normal -- hopefully nothing like silent corruption is going on. Also it's on brand new hardware...Intel ICH8 mobile chipset with AHCI. Output from dmesg, hdparm -I /dev/sda and hdparm --drq-hsm-error /dev/sda is below...please let me know if there's anything else that would be of use (and, of course, if this is something I should be worried about :-) ). Thanks. Jeff dmesg: ata1.00: exception Emask 0x2 SAct 0xfffd SErr 0x0 action 0x2 frozen ata1.00: spurious completions during NCQ issue=0x1 SAct=0xfffd FIS=005040a1:0002 ata1.00: cmd 61/08:00:56:4c:d4/00:00:01:00:00/40 tag 0 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:10:a6:fb:c5/00:00:01:00:00/40 tag 2 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:18:fe:00:c8/00:00:01:00:00/40 tag 3 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:20:be:e5:cf/00:00:01:00:00/40 tag 4 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:28:46:f6:cf/00:00:01:00:00/40 tag 5 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:30:96:ef:d3/00:00:01:00:00/40 tag 6 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:38:b6:ef:d3/00:00:01:00:00/40 tag 7 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:40:e6:ef:d3/00:00:01:00:00/40 tag 8 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/18:48:f6:ef:d3/00:00:01:00:00/40 tag 9 cdb 0x0 data 12288 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:50:86:02:d4/00:00:01:00:00/40 tag 10 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:58:a6:4b:d4/00:00:01:00:00/40 tag 11 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/10:60:ae:4b:d4/00:00:01:00:00/40 tag 12 cdb 0x0 data 8192 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/10:68:d6:4b:d4/00:00:01:00:00/40 tag 13 cdb 0x0 data 8192 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/18:70:06:4c:d4/00:00:01:00:00/40 tag 14 cdb 0x0 data 12288 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1.00: cmd 61/08:78:46:4c:d4/00:00:01:00:00/40 tag 15 cdb 0x0 data 4096 out res 50/00:08:46:4c:d4/00:00:01:00:00/40 Emask 0x2 (HSM violation) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/133 ata1: EH complete sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA hdparm -I /dev/sda: /dev/sda: ATA device, with non-removable media Model Number: Hitachi HTS722016K9A300 Serial Number: 071014DP1D10DFG5A80P Firmware Revision: DCDOC54P Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5; Revision: ATA8-AST T13 Project D1697 Revision 0b Standards: Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 268435455 LBA48 user addressable sectors: 312581808 device size with M = 1024*1024: 152627 MBytes device size with M = 1000*1000: 160041 MBytes (160 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Vendor, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 8 Advanced power management level: 128 (0x80) Recommended acoustic management value: 128, current value: 128 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: *SMART feature set Security Mode feature set *
nmi_watchdog killing tickless feature
Hi Please CC me on reply, i am not subscribed to list. I did small test, and notice that if nmi_watchdog is enabled mpstat 1 06:11:00 CPU %user %nice%sys %iowait%irq %soft %steal %idleintr/s 06:11:01 all0.000.000.000.000.000.000.00 100.00993.07 06:11:02 all0.000.000.000.000.000.000.00 100.00 1007.00 06:11:03 all0.000.000.000.000.000.000.00 100.00 1005.00 if disabled 06:13:52 CPU %user %nice%sys %iowait%irq %soft %steal %idleintr/s 06:13:53 all0.000.000.000.000.000.000.00 100.00 1.00 06:13:54 all0.000.000.000.000.000.000.00 100.00 9.00 06:13:55 all0.000.000.000.000.000.000.00 100.00 4.00 06:13:56 all0.000.000.000.000.000.000.00 100.00 2.00 06:13:57 all0.000.000.000.000.000.000.00 100.00 2.00 The difference is huge, probably in power consumption too. Kernel is relatively standard (2.6.24-rc6-git1), if required i can attach .config If it is not bug, probably good to document, that it is killing powersaving features? -- Denys Fedoryshchenko Technical Manager Virtual ISP S.A.L. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
> And is /sys/slab > guaranteed to be a stable and permanent interface if the SLAB Debugging feature and "stable and permanent" just don't fit together. It's like requesting stable and permanent sysrq output. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ACPI: _PTS ordering needs fixing for pre ACPI 3.0 systems (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
Adding Linux-ACPI to CC.
On Tuesday 25 December 2007 00:03:25 Carlos Corbacho wrote:
> According to the earlier versions of the ACPI spec, Linux is doing the
> wrong thing - we should call _PTS() before we start powerding down devices,
> or notifying device drivers to start suspending.
>
> So, my limited understanding of what we currently do for ACPI
> suspend-to-RAM is:
>
> 1) Freeze processes/ devices
> 2) Put all devices into low power mode
> 3) Execute _PTS()
> 4) Suspend system
>
> So the problem is - our current suspend order is fine for ACPI 3.0 and
> above, but for pre-3.0 systems, this violates the older specs, where 2) and
> 3) should be reversed.
The following is a hack to illustrate what I'm getting at (this is
tested on x86-64) (it's a hack since it does all the ACPI prepare bits
during set_target() for the pre ACPI 3.0 systems, rather than prepare() -
whether this can be cleaned up to move out just the _PTS() call, I don't
know).
It abuses suspend_ops->set_target(), but was the easiest way to quickly
demonstrate this (since the kerneldoc for set_target() says it will always
be executed before we suspend the devices).
-Carlos
---
drivers/acpi/sleep/main.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 96d23b3..89e708b 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -77,8 +77,19 @@ static int acpi_pm_set_target(suspend_state_t pm_state)
} else {
printk(KERN_ERR "ACPI does not support this state: %d\n",
pm_state);
- error = -ENOSYS;
+ return -ENOSYS;
}
+
+ /*
+* For ACPI 1.0 and 2.0 systems, we must run the preparation methods
+* before we put the devices into low power mode.
+*/
+ if (acpi_gbl_FADT.header.revision < 3) {
+ error = acpi_sleep_prepare(acpi_target_sleep_state);
+ if (error)
+ acpi_target_sleep_state = ACPI_STATE_S0;
+ }
+
return error;
}
@@ -91,10 +102,17 @@ static int acpi_pm_set_target(suspend_state_t pm_state)
static int acpi_pm_prepare(void)
{
- int error = acpi_sleep_prepare(acpi_target_sleep_state);
+ int error = 0;
- if (error)
- acpi_target_sleep_state = ACPI_STATE_S0;
+ /*
+* For ACPI 3.0 or newer systems, we must run the preparation methods
+* after we put the devices into low power mode.
+*/
+ if (acpi_gbl_FADT.header.revision >= 3) {
+ error = acpi_sleep_prepare(acpi_target_sleep_state);
+ if (error)
+ acpi_target_sleep_state = ACPI_STATE_S0;
+ }
return error;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "ip neigh show" not showing arp cache entries?
On Wed, Dec 19, 2007 at 08:28:49AM -0600, Chris Friesen wrote:
>
> I've included the traces below, they're pretty long. I don't know
> enough about the netlink format to trace the responses, but I did notice
> one interesting thing.
>
> In the "ip neigh show" case the "bond2" entry isn't printed out, but I
> can see the string "bond2" in the recvmsg() call so it looks like the
Actually bond2 isn't in the recvmsg, it's just that strace is
printing out the complete content of the buffer which happenes
to include bond2.
I've verified that the first recvmsg indeed does not contain the
bond2 address at all. Instead of the first 3 IPv4 records it has
3 IPv6 records. So we seem to have a kernel problem here.
However, too many changes have been made in this area since 2.6.14
for it to be worthwhile for me to debug this any further until you
manage to reproduce it with the current kernel.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Monday 24 December 2007 22:40:46 Robert Hancock wrote: > The ACPI spec has the following to say about the _PTS method: > > "The platform must not make any assumptions about the state of the > machine when _PTS is called. For example, operation region accesses that > require devices to be configured and enabled may not succeed, as these > devices may be in a non-decoding state due to plug and play or power > management operations." That is from the 3.0 spec though. And it looks like the definition changed from pre-3.0 to 3.0 and above. This is what the 1.0B spec says (and this is also repeated verbatim in 2.0, 2.0a, 2.0b, and 2.0c): "The _PTS control method is executed by the operating system at the beginning of the sleep process for S1, S2, S3, S4, and for orderly S5 shutdown. The sleeping state value (1, 2, 3, 4, or 5) is passed to the _PTS control method. Before the OS notifies native device drivers and prepares the system software for a system sleeping state, it executes this ACPI control method. Thus, this control method can be executed a relatively long time before actually entering the desired sleeping state. In addition, the OS can abort the sleeping operation without notification to the ACPI driver, in which case another _PTS would occur some time before the next attempt by the OS to enter a sleeping state. The _PTS control method cannot modify the current configuration or power state of any device in the system. For example, _PTS would simply store the sleep type in the embedded controller in sequencing the system into a sleep state when the SLP_EN bit is set." According to the earlier versions of the ACPI spec, Linux is doing the wrong thing - we should call _PTS() before we start powerding down devices, or notifying device drivers to start suspending. So, my limited understanding of what we currently do for ACPI suspend-to-RAM is: 1) Freeze processes/ devices 2) Put all devices into low power mode 3) Execute _PTS() 4) Suspend system So the problem is - our current suspend order is fine for ACPI 3.0 and above, but for pre-3.0 systems, this violates the older specs, where 2) and 3) should be reversed. > I would guess some BIOS writers failed to heed this.. No, it looks like the BIOS is obeying the older specs, and Linux is at fault here for breaking the suspend logic of pre ACPI 3.0 systems. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Mon, Dec 24, 2007 at 11:21:14AM -0800, Christoph Lameter wrote: > > That is why there is a slabinfo tool that does all the nice formatting. > > Do a > > gcc -o slabinfo Documentation/vm/slabinfo.c > > Then run slabinfo instead of doing cat /proc/slabinfo So two questions: why isn't -f the default? And is /sys/slab guaranteed to be a stable and permanent interface if the SLAB implementation ever gets ripped out? If so, maybe this should go into util-linux-ng? I am aa bit concerned about the lack of atomicity of /sys/slab, but this is a heck of a lot better of many kernel drivers or subsystems which use /sys and the completely punt on any kind of userspace utility, forcing users to type crazy things like echo 5 > /sys/bus/pci/drivers/iwl4965/*/power_level - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lockdep warning with LTP dio test (v2.6.24-rc6-125-g5356f66)
Setting: ltp-full-20071031, dio01 test on ext3 with Linus's latest tree.
Kernel w/ SMP, preemption, and lockdep configured.
Cheers,
Erez.
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc6 #83
---
diotest1/2088 is trying to acquire lock:
(>mmap_sem){}, at: [] dio_get_page+0x4e/0x15d
but task is already holding lock:
(jbd_handle){--..}, at: [] journal_start+0xcb/0xf8
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (jbd_handle){--..}:
[] __lock_acquire+0x9cc/0xb95
[] lock_acquire+0x5f/0x78
[] journal_start+0xee/0xf8
[] ext3_journal_start_sb+0x48/0x4a
[] ext3_dirty_inode+0x27/0x6c
[] __mark_inode_dirty+0x29/0x144
[] touch_atime+0xb7/0xbc
[] generic_file_mmap+0x2d/0x42
[] mmap_region+0x1e6/0x3b4
[] do_mmap_pgoff+0x1fb/0x253
[] sys_mmap2+0x9b/0xb5
[] syscall_call+0x7/0xb
[] 0x
-> #0 (>mmap_sem){}:
[] __lock_acquire+0x8bc/0xb95
[] lock_acquire+0x5f/0x78
[] down_read+0x3a/0x4c
[] dio_get_page+0x4e/0x15d
[] __blockdev_direct_IO+0x431/0xa81
[] ext3_direct_IO+0x10c/0x1a1
[] generic_file_direct_IO+0x124/0x139
[] generic_file_direct_write+0x56/0x11c
[] __generic_file_aio_write_nolock+0x33d/0x489
[] generic_file_aio_write+0x58/0xb6
[] ext3_file_write+0x27/0x99
[] do_sync_write+0xc5/0x102
[] vfs_write+0x90/0x119
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5f/0xa5
[] 0x
other info that might help us debug this:
2 locks held by diotest1/2088:
#0: (>s_type->i_mutex_key#6){--..}, at: []
generic_file_aio_write+0x45/0xb6
#1: (jbd_handle){--..}, at: [] journal_start+0xcb/0xf8
stack backtrace:
Pid: 2088, comm: diotest1 Not tainted 2.6.24-rc6 #83
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x6c/0x72
[] print_circular_bug_tail+0x5f/0x68
[] __lock_acquire+0x8bc/0xb95
[] lock_acquire+0x5f/0x78
[] down_read+0x3a/0x4c
[] dio_get_page+0x4e/0x15d
[] __blockdev_direct_IO+0x431/0xa81
[] ext3_direct_IO+0x10c/0x1a1
[] generic_file_direct_IO+0x124/0x139
[] generic_file_direct_write+0x56/0x11c
[] __generic_file_aio_write_nolock+0x33d/0x489
[] generic_file_aio_write+0x58/0xb6
[] ext3_file_write+0x27/0x99
[] do_sync_write+0xc5/0x102
[] vfs_write+0x90/0x119
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5f/0xa5
===
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Carlos Corbacho wrote: On Monday 24 December 2007 18:34:21 Linus Torvalds wrote: On Mon, 24 Dec 2007, Rafael J. Wysocki wrote: Well, having considered that for a longer while, I think the AML code is referring to a device that we have suspended already, and since it's in a low power state, it just can't handle the reference. If that is the case, we'll have to find the device (that should be possible using some code instrumentation) and move the suspending of it into the late stage. Yes. My own experimentation (in device_suspend(), calling _PTS() in the AML after each suspend_device() runs, until one device causes it to hang) points to ohci_hcd being the culprit here (with or without any devices attached). With the ohci_hcd module unloaded, the machine suspends just fine[1]. Of course, I'm at a complete loss as to why suspending OHCI would cause a problem for an IO port write. The name of the operation region, SMIP, suggests that the BIOS has an SMI trap on that port. In that case, writing to that port will result in the BIOS taking control. We have little idea what it could be doing. Could be it's trying to access the OHCI controller which has been suspended already. This sounds kind of like the Toshiba laptops that go nuts somewhere if the AHCI SATA controller gets put into suspend state before the system suspends.. The ACPI spec has the following to say about the _PTS method: "The platform must not make any assumptions about the state of the machine when _PTS is called. For example, operation region accesses that require devices to be configured and enabled may not succeed, as these devices may be in a non-decoding state due to plug and play or power management operations." I would guess some BIOS writers failed to heed this.. NOTE! This following patch is just for discussion, and while I think it's conceptually a good thing to try, I don't think it will help Carlos' problem. But removing the "pci_set_power_state()" in agp_nvidia_suspend() might. nvidia-agp cannot be built on x86-64, so it's not the culprit in this case. Yeah, and this is a PCI Express system not AGP, so it wouldn't load anyway. -- 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: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Monday 24 December 2007 18:34:21 Linus Torvalds wrote: > On Mon, 24 Dec 2007, Rafael J. Wysocki wrote: > > Well, having considered that for a longer while, I think the AML code is > > referring to a device that we have suspended already, and since it's in a > > low power state, it just can't handle the reference. > > > > If that is the case, we'll have to find the device (that should be > > possible using some code instrumentation) and move the suspending of it > > into the late stage. > > Yes. My own experimentation (in device_suspend(), calling _PTS() in the AML after each suspend_device() runs, until one device causes it to hang) points to ohci_hcd being the culprit here (with or without any devices attached). With the ohci_hcd module unloaded, the machine suspends just fine[1]. Of course, I'm at a complete loss as to why suspending OHCI would cause a problem for an IO port write. > NOTE! This following patch is just for discussion, and while I think it's > conceptually a good thing to try, I don't think it will help Carlos' > problem. But removing the "pci_set_power_state()" in agp_nvidia_suspend() > might. nvidia-agp cannot be built on x86-64, so it's not the culprit in this case. -Carlos [1] And yes, I double checked the custom DSDT is not loaded this time. -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Mon, Dec 24, 2007 at 10:51:22AM -0800, Linus Torvalds wrote: > The *second* problem is entirely a kernel internal issue. It's the one > that causes us the biggest issues right now, but it's also the one that > will not impact user space at all once if is fixed. So once we do the > *early* probing using anything but mmconfig accesses, we can then much > more easily enable mmconfig later, and by the time the user does anything > like "lspci -vvv", we could do those mmconfig accesses. I had a nice idea to fix this ... will post a patch to do that later. > I also suspect that we *may* want to use a separate file for the extended > config. Right now, things like lspci read the config space by accessing > a file like > > /sys/bus/pci/devices/:00:00.0/config > > and I'm not at all sure we want to extend that one past the first 256 > bytes of config space. Why? Because I don't want old programs that may not > know how dangerous the rest of the space is to read extended config space > by mistake when they don't know how to parse it anyway. Unless we're talking about crazy, crazy programs that blindly open and read every file in sysfs as root (yes, they exist, and they already cause problems simply by reading past the first 64 bytes of config space which causes problems for, eg, sym53c875 cards), non-root accesses are already restricted to the first 64 bytes, so it's no more of a problem than it currently is. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PNP: add all PNP card device id's as individual aliases
From: Kay Sievers <[EMAIL PROTECTED]>
Subject: PNP: add all PNP card device id's as individual aliases
The current PNP combined card + devices module aliase can
never ever match anything, because all these values are never
available all at the same time to match a module.
Instead of adding the useless combined alias, we add the device
id's all as individual aliases. Device id's are exported by the PNP
bus, and can now properly used to request the loading of a
matching module.
The module snd-sbawe currently exports aliases, who can never
match any device:
alias: pnp:cCTLdCTL0045dCTL0022*
alias: pnp:cCTLdCTL0044dCTL0023*
alias: pnp:cCTLdCTL0042dCTL0022*
alias: pnp:cCTLdCTL0041dCTL0021*
alias: pnp:cCTLdCTL0031dCTL0021*
alias: pnp:cCTL00eddCTL0041dCTL0070*
alias: pnp:cCTL00e9dCTL0045dCTL0022*
alias: pnp:cCTL00e4dCTL0045dCTL0022*
alias: pnp:cCTL00c7dCTL0045dCTL0022*
alias: pnp:cCTL00c5dCTL0045dCTL0022*
alias: pnp:cCTL00c3dCTL0045dCTL0022*
alias: pnp:cCTL00c1dCTL0042dCTL0022*
alias: pnp:cCTL00b2dCTL0044dCTL0023*
alias: pnp:cCTL009edCTL0044dCTL0023*
alias: pnp:cCTL009ddCTL0042dCTL0022*
alias: pnp:cCTL009fdCTL0041dCTL0021*
alias: pnp:cCTL009cdCTL0041dCTL0021*
alias: pnp:cCTL009adCTL0041dCTL0021*
alias: pnp:cCTL0054dCTL0031dCTL0021*
alias: pnp:cCTL0048dCTL0031dCTL0021*
alias: pnp:cCTL0047dCTL0031dCTL0021*
alias: pnp:cCTL0046dCTL0031dCTL0021*
alias: pnp:cCTL0045dCTL0031dCTL0021*
alias: pnp:cCTL0044dCTL0031dCTL0021*
alias: pnp:cCTL0043dCTL0031dCTL0021*
alias: pnp:cCTL0042dCTL0031dCTL0021*
alias: pnp:cCTL0039dCTL0031dCTL0021*
alias: pnp:cCTL0035dCTL0031dCTL0021*
With this patch it exports only the device id's, as matchable
aliases:
alias: pnp:dCTL0070*
alias: pnp:dCTL0045*
alias: pnp:dCTL0023*
alias: pnp:dCTL0044*
alias: pnp:dCTL0022*
alias: pnp:dCTL0042*
alias: pnp:dCTL0041*
alias: pnp:dCTL0021*
alias: pnp:dCTL0031*
Now, the exported value of the PNP bus can be used to autoload
a matching module:
$ modprobe --first-time -n -v pnp:dCTL0045
insmod
/lib/modules/2.6.24-rc6-g5b825ed2-dirty/kernel/sound/core/snd-rawmidi.ko
insmod
/lib/modules/2.6.24-rc6-g5b825ed2-dirty/kernel/sound/drivers/mpu401/snd-mpu401-uart.ko
insmod /lib/modules/2.6.24-rc6-g5b825ed2-dirty/kernel/sound/core/snd-hwdep.ko
insmod
/lib/modules/2.6.24-rc6-g5b825ed2-dirty/kernel/sound/isa/sb/snd-sb-common.ko
insmod
/lib/modules/2.6.24-rc6-g5b825ed2-dirty/kernel/sound/isa/sb/snd-sb16-csp.ko
insmod
/lib/modules/2.6.24-rc6-g5b825ed2-dirty/kernel/sound/isa/sb/snd-sb16-dsp.ko
insmod
/lib/modules/2.6.24-rc6-g5b825ed2-dirty/kernel/sound/drivers/opl3/snd-opl3-lib.ko
insmod
/lib/modules/2.6.24-rc6-g5b825ed2-dirty/kernel/sound/isa/sb/snd-sbawe.ko
$ grep CTL0045 /sys/bus/pnp/devices/*/id
/sys/bus/pnp/devices/01:01.00/id:CTL0045
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
---
file2alias.c | 57 -
1 file changed, 44 insertions(+), 13 deletions(-)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index d802b5a..1882889 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -324,19 +324,52 @@ static int do_pnp_entry(const char *filename,
return 1;
}
-/* looks like: "pnp:cCdD..." */
-static int do_pnp_card_entry(const char *filename,
- struct pnp_card_device_id *id, char *alias)
+/* looks like: "pnp:dD" for every device of the card */
+static void do_pnp_card_entries(void *symval, unsigned long size,
+ struct module *mod)
{
- int i;
+ const unsigned long id_size = sizeof(struct pnp_card_device_id);
+ const unsigned int count = (size / id_size)-1;
+ const struct pnp_card_device_id *cards = symval;
+ unsigned int i;
- sprintf(alias, "pnp:c%s", id->id);
- for (i = 0; i < PNP_MAX_DEVICES; i++) {
- if (! *id->devs[i].id)
- break;
- sprintf(alias + strlen(alias), "d%s", id->devs[i].id);
+ device_id_check(mod->name, "pnp", size, id_size, symval);
+
+ for (i = 0; i < count; i++) {
+ unsigned int j;
+ const struct pnp_card_device_id *card = [i];
+
+ for (j = 0; j < PNP_MAX_DEVICES; j++) {
+ const char *id = (char *)card->devs[j].id;
+ int i2, j2;
+ int dup = 0;
+
+ if (!id[0])
+ break;
+
+ /* find duplicate, already added value */
+ for (i2 = 0; i2 < i && !dup; i2++) {
+ const struct pnp_card_device_id *card2 =
[i2];
+
+ for (j2 = 0; j2 < PNP_MAX_DEVICES; j2++) {
+ const char *id2 = (char
*)card2->devs[j2].id;
+
+ if (!id2[0])
+
Re: [PATCH] slub: /proc/slabinfo ABI compatibility
On Dec 24, 2007 9:12 PM, Christoph Lameter <[EMAIL PROTECTED]> wrote: > Hmmm... What is the combination of config variables that causes this? I > moved the count_partial function in mm in order to make the merge of slab > defrag easier. I think it's CONFIG_PROC_FS without CONFIG_SYSFS. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LINUX kernel 2.6.23: bug in CIFSSMBSetEA
Hello
In fs/cifs/cifssmb.c, in CIFSSMBSetEA (...) function wrong counting of
var exists.
EXISTING CODE:
pSMB->DataCount = sizeof(*parm_data) + ea_value_len + name_len + 1;
MUST BE:
pSMB->DataCount = sizeof(*parm_data) + ea_value_len + name_len;
REASON:
"sizeof(*parm_data)" counts 1 byte from "char name[1];"
So, for example in Samba server (sources/smbd/trans2.c), we can see
wrong processing of EA, cause data sent to server is bigger on 1 byte
then it must be.
See Extra info for details
- Extra info
struct fealist *parm_data;
1707 struct fea {
1708 unsigned char EA_flags;
1709 __u8 name_len;
1710 __u16 value_len;
1711 char name[1];
1712 /* optionally followed by value */
1713 };
1714 /* flags for _FEA.fEA */
1715 #define FEA_NEEDEA 0x80 /* need EA bit */
1716
1717 struct fealist {
1718 __u32 list_len;
1719 struct fea list[1];
1720 };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Strange Panic (Deadlock)
[EMAIL PROTECTED] wrote, On 12/24/2007 07:18 PM: > Hello again. > Its bug depend to > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4aae07025265151e3f7041dfbf0f529e122de1d8 > ? Hello Vyacheslav! I wonder why do you think there is such a dependency, and why do you report timer.c bug to netdev after all? I added some CCs here, but IMHO you would better open a new bug at bugzilla.kernel.org, adding some more details like .config, and reply back to this thread with the bug's number. BTW, if it's patched by Gentoo or otherwise, you should try and report on 'vanilla' one only. Regards, Jarek P. > Its very critical bug to us. This PC must be HA. Server place so far > for me to go and reboot server. I go to it 1-3 times in week =( > Please help to fix it =) > >> Hello all. Some time machine freeze. No information on monitor. No >> rebooting on sysctl "kernel.panic". >> Any idea? >> >> Catched by netconsole: >> [91922.085864] [ cut here ] >> [91922.085975] kernel BUG at kernel/timer.c:606! >> [91922.086058] invalid opcode: [#1] >> [91922.086127] SMP >> [91922.086201] Modules linked in: netconsole cls_u32 sch_sfq sch_htb >> xt_tcpudp iptable_filter ip_tables x_tables i2c_i801 i2c_core >> [91922.086386] CPU:1 >> [91922.086387] EIP:0060:[]Not tainted VLI >> [91922.086389] EFLAGS: 00010087 (2.6.23-gentoo-r4-fw #4) >> [91922.086600] EIP is at cascade+0x34/0x4f >> [91922.086669] eax: c0452200 ebx: f450408c ecx: 0022 edx: f3c6e08c >> [91922.086740] esi: 0022 edi: c21ce000 ebp: 0001 esp: c21c3ef8 >> [91922.086815] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 >> [91922.086885] Process swapper (pid: 0, ti=c21c2000 task=c21af000 >> task.ti=c21c2000) >> [91922.086954] Stack: f3c6e08c c21bfb74 c21ce000 000a >> c012767a c21af000 0001 >> [91922.087119]c21c3f18 c0106963 c21c3f68 0001 0021 >> c03c0b08 000a c0124556 >> [91922.087285]0046 c21c2008 c01245ec >> c2015120 c0114a11 0046 >> [91922.087451] Call Trace: >> [91922.087586] [] run_timer_softirq+0x51/0x154 >> [91922.087669] [] profile_pc+0x21/0x46 >> [91922.087752] [] __do_softirq+0x5d/0xc1 >> [91922.087833] [] do_softirq+0x32/0x36 >> [91922.087915] [] smp_apic_timer_interrupt+0x74/0x80 >> [91922.087997] [] apic_timer_interrupt+0x28/0x30 >> [91922.088076] [] mwait_idle_with_hints+0x3b/0x3f >> [91922.088162] [] mwait_idle+0x0/0xa >> [91922.088237] [] cpu_idle+0x91/0xaa >> [91922.088319] === >> [91922.088390] Code: 08 8d 04 ca 8b 10 89 62 04 89 14 24 8b 50 04 89 22 >> 89 00 89 54 24 04 8b 14 24 89 40 04 8b 1a eb 19 8b 42 14 83 e0 fe 39 f8 >> 74 04 <0f> 0b eb fe 89 f8 e8 d8 fe ff ff 89 da 8b 1b 39 e2 75 e3 59 89 >> [91922.088864] EIP: [] cascade+0x34/0x4f SS:ESP 0068:c21c3ef8 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe netdev" in >> the body of a message to [EMAIL PROTECTED] >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > > > > > This message was sent using IMP, the Internet Messaging Program. > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.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: tlb_finish_mmu() bogisity
On Sun, 23 Dec 2007, Linus Torvalds wrote:
> > What did you intend here? s/&//, perhaps?
>
> I think that thing is bogus in other ways. It plays games with
> "needs_flush", just because it seems to want the generic code to then call
> "check_pgt_cache()", not because it actually wants any flushing to take
> place.
It can only free the pages on the quicklist after the flush. So it needs
to set need_flush to trigger the flush before check_pgt_cache can trim the
quicklist. If need_flush is not set then pages are freed in
check_pgt_cache before their TLBs have been flushed.
> Or is there any other reason going on here? That quicklist stuff has been
> totally broken, it's done too many totally invalid things to really be
> worth even keeping. We should get rid of that unmaintainable hack, and if
> it has a real performance upside, we should make it part of the *native*
> mmu-gather infrastructure, instead of maintaining it as some separate and
> buggy/unmaintainable piece-of-sh*t code.
Yup as we agreed before it would be best to make the TLB pieces part of
the native mmu gather infrastructure. But then they vary quite a lot
between arches.
Quicklist: Remove bogus &
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6/include/asm-generic/tlb.h
===
--- linux-2.6.orig/include/asm-generic/tlb.h2007-12-24 10:53:52.0
-0800
+++ linux-2.6/include/asm-generic/tlb.h 2007-12-24 10:54:01.0 -0800
@@ -87,7 +87,7 @@ static inline void
tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
{
#ifdef CONFIG_QUICKLIST
- tlb->need_flush += &__get_cpu_var(quicklist)[0].nr_pages != 0;
+ tlb->need_flush += __get_cpu_var(quicklist)[0].nr_pages != 0;
#endif
tlb_flush_mmu(tlb, start, end);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Sat, 22 Dec 2007, Ingo Molnar wrote: > Christoph, i'd like to apologize for all overly harsh words i said. (and > i said quite a few :-/ ) Looks like a bad interaction due to overload, vacation, flu epidemic hitting me and family and also Christmas coming up so that I could not do my usual workload. Need to find some way to cut back on the stuff that I am involved with it seems. Thanks for the SLUB patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Sun, 23 Dec 2007, Theodore Tso wrote: > > tends to work reasonably well for a quick overview, but yes > > cat was nicer for humans. > > Until you start to wonder what the heck :a-136 is: > > /sys/slab/:a-136/objs_per_slab: 30 > > Sigh... That is why there is a slabinfo tool that does all the nice formatting. Do a gcc -o slabinfo Documentation/vm/slabinfo.c Then run slabinfo instead of doing cat /proc/slabinfo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build breakage on powerpc with 2.6.24-rc6-mm1
On Sun, Dec 23, 2007 at 08:49:12PM -0800, Greg KH wrote: > > Hi Greg, do you even build with your patches applied? > > For the power architecture, no, I do not. I used to, but my cross-build > box died and I haven't taken the time to set it all up again. Crosstool makes it really easy. It's demo-powerpc-970.sh will build a toolchain that can build both 32- and 64-bit powerpc kernels. It's got a demo-s390.sh as well, but I haven't tried that one myself. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] slub: /proc/slabinfo ABI compatibility
On Sat, 22 Dec 2007, Ingo Molnar wrote: > Pekka, i stuck your patch into the x86.git random-test-grid, and it > found the following build error after a few iterations: > > mm/slub.c: In function 's_show': > mm/slub.c:4188: error: implicit declaration of function 'count_partial' > > find the (tested) fix below. Hmmm... What is the combination of config variables that causes this? I moved the count_partial function in mm in order to make the merge of slab defrag easier. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Mon, 24 Dec 2007, Jeff Garzik wrote:
>
> Definitely. So, two questions:
>
> What's the preferred way to deal with the desire to view extended config space
> with "lspci -vvvxxx"?
Well, there's two issues right now with MMCONFIG
- we've hit various bugs in it. The bugs are admittedly very rare, but
they are really painful when they happen.
This is the more "fundamental" of the problems, and this is the one
that means that on some machines, the answer to the above question will
simply *always* be that we simply will never *ever* show the extended
config space - because even though it might work, we are going to
decide that it's simply too dangerous.
(Hypothetical example: we might, for example, end up saying that we
will simply never enable mmconfig at all unless the BIOS DMI date says
that the motherboard was built in 2008 or later)
- the (currently more common) problem that our initial probing is totally
screwed up with mmconfig.
This is the thing that causes *most* of our current problems, and the
fact is, we absolutely cannot do the initial kernel PCI probing using
mmconfig accesses. Not only do we not have enough information about the
resources yet at that stage to decide sanely whether mmconfig can
really work, but it is my sincere hope that some day the mmconfig MMIO
region itself will be defined by some standard BAR etc, so trying to
probe the BARs using mmconfig would be a chicken-and-egg problem.
There's also the issue that we want to often *validate* the mmconfig
address using config space accesses, and right now we have some really
ugly code that actually uses "pci_conf1_read()" _explicitly_ to avoid
using mmconfig for this (see arch/x86/pci/mmconfig-shared.c).
The *second* problem is entirely a kernel internal issue. It's the one
that causes us the biggest issues right now, but it's also the one that
will not impact user space at all once if is fixed. So once we do the
*early* probing using anything but mmconfig accesses, we can then much
more easily enable mmconfig later, and by the time the user does anything
like "lspci -vvv", we could do those mmconfig accesses.
I also suspect that we *may* want to use a separate file for the extended
config. Right now, things like lspci read the config space by accessing
a file like
/sys/bus/pci/devices/:00:00.0/config
and I'm not at all sure we want to extend that one past the first 256
bytes of config space. Why? Because I don't want old programs that may not
know how dangerous the rest of the space is to read extended config space
by mistake when they don't know how to parse it anyway.
So I would *suggest* (but this may be overly cautious) that we at least
consider forcing people who actually want to read extended config space to
have to use a separate file for it ("/sys/.../extended-config"), because
that would then also be a sign to the kernel that "ok, the user really
asked for us to use mmconfig cycles here".
> Is there a path for hw vendors, after passing 1,001 anal checks, to maintain
> the current behavior as it exists today in arch/x86/pci/mmconfig_{32,64}.c?
Well, the *current* behaviour as far as setup is concerned is
unacceptable. But yes, longer term, we should be able to just have quirk
entries for saying "enable mmconfig because I know it's safe", except we
should not enable them until after the core PCI probing has completed.
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: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Mon, 24 Dec 2007, Rafael J. Wysocki wrote:
>
> Well, having considered that for a longer while, I think the AML code is
> referring to a device that we have suspended already, and since it's in a low
> power state, it just can't handle the reference.
>
> If that is the case, we'll have to find the device (that should be possible
> using some code instrumentation) and move the suspending of it into the late
> stage.
Yes.
In general, I'm personally of the opinion that drivers should *not*
actually go into D3 at all in the regular "->suspend()" phase. It should
be done in ->suspend_late. The early suspend is for saving state and
returning errors.
Sadly, we've made it a bit too inconvenient to actually do that. Almost
all drivers only do the "->suspend" thing, and the default PCI behaviour
doesn't help us in any way either.
Anyway, I wonder if a patch like this could make it easier for driver
writers to handle things. It basically does:
- if you don't have a regular "suspend()" function, we'll just save state
at suspend time.
- if you don't have a "suspend_late()" function, we'll look at the
current state, and if it's still in PCI_D0, we'll suspend to PCI_D3hot
if it's a regular PCI device (ie not a bridge or something else odd).
- then, at resume time, by default we don't do anything in the early
resume, but in the late resume we'll undo everything, of course.
Anyway, with this, most drivers could just remove the
"pci_set_power_state()" call *entirely*, and let the default
suspend_late action power the device down. But if you want to override
that default action, you can either:
- set the power state in your own ->suspend() routine (either by using
pci_set_power_state(), or by just explicitly setting the state to
unknown with "dev->current_state = PCI_UNKNOWN"
- have a "late_suspend()" action, which obviously will override the
default action entirely.
Hmm?
In the case of the NVidia issue, one thing to try migh be to remove the
current call to "pci_set_power_state(pdev, 3);" in agp_nvidia_suspend() in
drivers/char/agp/nvidia-agp.c. That sounds like the most likely culprit
for something that ACPI might want to shut down.
NOTE! This following patch is just for discussion, and while I think it's
conceptually a good thing to try, I don't think it will help Carlos'
problem. But removing the "pci_set_power_state()" in agp_nvidia_suspend()
might.
Linus
---
drivers/pci/pci-driver.c | 32 +---
1 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 6d1a216..6992f73 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -264,6 +264,28 @@ static int pci_device_remove(struct device * dev)
return 0;
}
+static void pci_default_suspend(struct pci_dev *dev, pm_message_t state)
+{
+ pci_save_state(dev);
+}
+
+static void pci_default_suspend_late(struct pci_dev *dev, pm_message_t state)
+{
+ /* Something has already suspended it? Never mind then.. */
+ if (dev->current_state != PCI_D0)
+ return;
+
+ /* We avoid powering down bridges by default.. */
+ if (dev->hdr_type == PCI_HEADER_TYPE_NORMAL)
+ pci_set_power_state(dev, PCI_D3hot);
+
+ /*
+* mark its power state as "unknown", since we don't know if
+* e.g. the BIOS will change its device state when we suspend.
+*/
+ dev->current_state = PCI_UNKNOWN;
+}
+
static int pci_device_suspend(struct device * dev, pm_message_t state)
{
struct pci_dev * pci_dev = to_pci_dev(dev);
@@ -274,13 +296,7 @@ static int pci_device_suspend(struct device * dev,
pm_message_t state)
i = drv->suspend(pci_dev, state);
suspend_report_result(drv->suspend, i);
} else {
- pci_save_state(pci_dev);
- /*
-* mark its power state as "unknown", since we don't know if
-* e.g. the BIOS will change its device state when we suspend.
-*/
- if (pci_dev->current_state == PCI_D0)
- pci_dev->current_state = PCI_UNKNOWN;
+ pci_default_suspend(pci_dev, state);
}
return i;
}
@@ -294,6 +310,8 @@ static int pci_device_suspend_late(struct device * dev,
pm_message_t state)
if (drv && drv->suspend_late) {
i = drv->suspend_late(pci_dev, state);
suspend_report_result(drv->suspend_late, i);
+ } else {
+ pci_default_suspend_late(pci_dev, state);
}
return i;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] powerpc: DBox2 Board Support
On Sunday 23 December 2007, Jochen Friedrich wrote:
> This patch adds device tree source, default config and setup code for
> DBox2 devices.
Cool stuff. I used to have one of these boxes myself, maybe I should
get one again when it's hitting mainline.
Is this already a complete port, or do you also need some device
drivers or boot wrapper code to go along with it?
> + memory {
> + device_type = "memory";
> + reg = <0 200>;
> + };
I thought there are both models with 32MB and 16MB available.
If that's true, shouldn't this be filled out by the boot loader?
> +#
> +# Frame buffer hardware drivers
> +#
> +# CONFIG_FB_OF is not set
> +# CONFIG_FB_VGA16 is not set
> +# CONFIG_FB_S1D13XXX is not set
> +# CONFIG_FB_IBM_GXT4500 is not set
> +# CONFIG_FB_VIRTUAL is not set
> +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
No hardware framebuffer driver? Can't you use
the FB_OF driver by default? I'd guess that a
set-top box without output is rather pointless ;-)
> +# DOS/FAT/NT Filesystems
> +#
> +CONFIG_FAT_FS=y
> +CONFIG_MSDOS_FS=y
> +CONFIG_VFAT_FS=y
> +CONFIG_FAT_DEFAULT_CODEPAGE=437
> +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
> +# CONFIG_NTFS_FS is not set
What media can you connect that use the FAT file system?
I'd guess that if you can get rid of these, you can also
disable the entire block layer, which should free up
some kernel memory.
> @@ -0,0 +1,30 @@
> +/*
> + * A collection of structures, addresses, and values associated with
> + * the DBox2.
> + *
> + * Author: (c) 2007 Jochen Friedrich
> + *
> + * This file is licensed under the
> + * terms of the GNU General Public License version 2. This program is
> licensed
> + * "as is" without any warranty of any kind, whether express or implied.
> + */
> +
> +#ifdef __KERNEL__
> +#ifndef __ASM_DBOX2_H__
> +#define __ASM_DBOX2_H__
You don't need the #ifdef __KERNEL__ any more if you don't have
any user-visible parts in the header. Just leave it out of the
list of exported header files (as you already do).
> +
> +/* Vendor information in BR Bootloader
> + */
> +
> +#define DBOX2_VENDOR_OFFSET (0x1ffe0)
> +
> +enum dbox2_mid {
> + DBOX2_MID_NOKIA = 1,
> + DBOX2_MID_PHILIPS = 2,
> + DBOX2_MID_SAGEM = 3,
> +};
> +
> +enum dbox2_mid dbox2_get_mid(void);
Can you move this functionality from the kernel to the boot wrapper?
It looks like this is something that really belongs into the device
tree.
> +static void __init dbox2_setup_arch(void)
> +{
> + struct device_node *np;
> + static u8 __iomem *config;
> +
> + cpm_reset();
> + init_ioports();
> +
> + /* Enable external IRQs for AVIA chips */
> + clrbits32(_immr->im_siu_conf.sc_siumcr, 0x0c00);
This smells like a hack. What are AVIA chips, and shouldn't
their driver enable the IRQs?
> + if (dbox2_manuf_id == DBOX2_MID_NOKIA)
> + np = of_find_node_by_path("/[EMAIL PROTECTED]/[EMAIL
> PROTECTED]");
> + else
> + np = of_find_node_by_path("/[EMAIL PROTECTED]/[EMAIL
> PROTECTED]");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +
> + if (dbox2_manuf_id == DBOX2_MID_PHILIPS)
> + np = of_find_node_by_path("/[EMAIL PROTECTED]/[EMAIL
> PROTECTED]");
> + else
> + np = of_find_node_by_path("/[EMAIL PROTECTED]/[EMAIL
> PROTECTED]");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +}
What is this code for? Why do you want to detach nodes from the device
tree that have been put in there by the boot loader?
> +static struct of_device_id __initdata of_bus_ids[] = {
> + { .name = "soc", },
> + { .name = "cpm", },
> + { .name = "localbus", },
> + {},
> +};
Shouldn't this check for 'compatible' properties instead of 'name'?
> +static int __init declare_of_platform_devices(void)
> +{
> + /* Publish the QE devices */
> + if (machine_is(dbox2))
> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(declare_of_platform_devices);
This is a candidate for the new platform_initcall stuff.
I also once did a patch that let you have a default 'of_bus_ids'
member in the ppc_md. I never got around to submitting that, but
if there is interest, I can dig it out again.
> --- a/include/asm-powerpc/mpc8xx.h
> +++ b/include/asm-powerpc/mpc8xx.h
> @@ -23,6 +23,10 @@
> #include
> #endif
>
> +#if defined(CONFIG_DBOX2)
> +#include
> +#endif
> +
Don't hide #includes or platform specific #defines in #ifdef.
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: [PATCH 30/38] net/bridge: Use time_before, time_before_eq, etc.
On Mon, 24 Dec 2007 15:45:32 +0100 (CET)
Julia Lawall <[EMAIL PROTECTED]> wrote:
> From: Julia Lawall <[EMAIL PROTECTED]>
>
> The functions time_before, time_before_eq, time_after, and time_after_eq
> are more robust for comparing jiffies against other values.
>
> A simplified version of the semantic patch making this change is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
>
> //
> @ change_compare_np @
> expression E;
> @@
>
> (
> - jiffies <= E
> + time_before_eq(jiffies,E)
> |
> - jiffies >= E
> + time_after_eq(jiffies,E)
> |
> - jiffies < E
> + time_before(jiffies,E)
> |
> - jiffies > E
> + time_after(jiffies,E)
> )
>
> @ include depends on change_compare_np @
> @@
>
> #include
>
> @ no_include depends on !include && change_compare_np @
> @@
>
> #include
> + #include
> //
>
> Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
> ---
>
> diff -r -u -p a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
> --- a/net/bridge/br_netfilter.c 2007-11-15 15:09:37.0 +0100
> +++ b/net/bridge/br_netfilter.c 2007-12-23 20:30:40.0 +0100
> @@ -46,6 +46,7 @@
> #include "br_private.h"
> #ifdef CONFIG_SYSCTL
> #include
> +#include
> #endif
>
> #define skb_origaddr(skb) (((struct bridge_skb_cb *) \
> @@ -221,7 +222,7 @@ static void __br_dnat_complain(void)
> {
> static unsigned long last_complaint;
>
> - if (jiffies - last_complaint >= 5 * HZ) {
> + if (time_before_eq(jiffies, last_complaint + 5 * HZ)) {
> printk(KERN_WARNING "Performing cross-bridge DNAT requires IP "
> "forwarding to be enabled\n");
> last_complaint = jiffies;
I would recommend changing this to net_ratelimit() instead.
--
Stephen Hemminger <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]
Loic Prylli wrote: I just realized one thing: the bar sizing code in pci_read_bases() (that writes 0x in the bars) does not seem to disable the PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the cmd register before manipulating the BARs. And it seems nobody else ensures they are disabled at this point either (or am I missing something?). No you're not missing anything. This problem causes many machines to break horribly when MMCONFIG is enabled. There's a patch in -mm to fix this. (It special-cases the case of host bridges and doesn't disable the decode bits for those, since some are known to do crazy things if you do that.) http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/broken-out/pci-disable-decoding-during-sizing-of-bars.patch Touching the bars while they are enabled would be buggy behaviour from our part, and something trivial to fix. And it might well fix that particular problem (it's fair play from the machine to crash if we create a decoding conflict, simply disabling the cmd bits in pci_read_bases() should remove that conflict). FWIW, to partially answer your last question, Windows does disable mem-space and/or IO-space when sizing the bars of a device (I have some traces of configuration-space-access taken on a window machine for one of the PCI busses). Good to know. There was some speculation that it did not. -- 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: [Bug 9528] x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Linus Torvalds wrote: On Sun, 23 Dec 2007, Carlos Corbacho wrote: Fix suspend-to-RAM on nForce 4 (CK804) boards by increasing PCIBIOS_MIN_IO. Fixes kernel bugzilla #9528 Problem: Linus' patch (52ade9b3b97fd3bea42842a056fe0786c28d0555) to re-order suspend (and fix fall out from Rafael's earlier suspend reordering work) broke suspend-to-RAM on nForce 4 (CK804) boards. Why: After debugging _PTS() in the DSDT, it turns out these nVidia boards are trying to write to an IO port > 0x1000 (0x142E) during suspend. Before the re-ordering, we got away with this. Very interesting. HOWEVER. I'd much rather figure out what the magic IO resource is that clashes. It's almost certainly some hidden and undocumented (or badly documented) ACPI IO area that the kernel doesn't know about, because it's not a regular PCI BAR resource, but some northbridge (or southbridge) magic register range. Those ranges *should* be reserved by the BIOS in the ACPI tables, but this would definitely not be the first time that doesn't happen. I'm having trouble sorting out which report is for which BIOS (and some of them don't have any dmesg posted), but I believe in these cases that memory region is indeed reported as reserved by the BIOS, and no PCI resources should end up allocated there. So I'm not sure why fiddling with PCIBIOS_MIN_IO would have any effect (other than by accident). I wonder if this is the culprit (from Arthur Erhardt's dmesg): pnpacpi: exceeded the max number of mem resources: 12 pnpacpi: exceeded the max number of mem resources: 12 which means we're ignoring some of the memory reservations. I wonder if some IO reservations are also being ignored? Why do we have this silly hard limit of number of resources anyway? If we just ignore random reservations provided by the BIOS, we shouldn't be surprised if things break randomly. This warning at the very least should be much louder (i.e. "Warning: This problem may break your system").. But the right fix would be for us to just figure out what the range is ass a PCI quirk, and just know to avoid it on purpose, ratehr than just being lucky and happen to avoid it because PCIBIOS_MIN_IO just happens to be bigger than the particular address. So can you: - show what your /proc/ioports contains (*with* the bug triggering, ie non-working suspend, so we see what it is that actually ends up using that area) - send out 'dmesg' for a boot (same deal) - add "lspci -xxxvv" output to the deal too. and also make them part of the bugzilla history (I'm cc'ing bugzilla here, and added the bug number to the subject, so hopefully this thread ends up being archived there too). There was some previous work in the PCIBIOS_MIN_IO area over two years ago (71db63acff69618b3d9d3114bd061938150e146b) which bumped this to 0x4000, but this was reverted (2ba84684e8cf6f980e4e95a2300f53a505eb794e) after causing new and entirely different problems on another nForce board. The problem here is classic: these magic ranges tend to be *different* on different boards (because they don't tend to be fixed by hardware, they are programmed regions set up by firmware), so trying to change PCIBIOS_MIN_IO to avoid a problem on one board is almost certain to just introduce it on another board instead. On *your* particular board, 0x142E is used for something, but on somebody elses board it might be 0x162E, and now changing PCIBIOS_MIN_IO to 0x1500 might make that other board hang instead. So you seem to have debugged this very successfully, and I'm wondering if you might be able to find out where that 0x142e comes from, and we could fix it for *all* boards using that chipset by just figuring out what the *hardware* rules (rather than the random firmware setup that will be different on different boards) for that chipset actually are! I suspect it's board specific. Looking at the DSDT for my A8N-SLI Deluxe, that SMIP region is defined at 0x442E (and is reported as reserved). This BIOS doesn't write there in the _PTS method like the ones in the report apparently do though. -- 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: [PATCH 1/38] arch/alpha: Use time_before, time_before_eq, etc.
Please ignore this patch, in which I have found an error.
julia
On Mon, 24 Dec 2007, Julia Lawall wrote:
> From: Julia Lawall <[EMAIL PROTECTED]>
>
> The functions time_before, time_before_eq, time_after, and time_after_eq
> are more robust for comparing jiffies against other values.
>
> A simplified version of the semantic patch making this change is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
>
> //
> @ change_compare_np @
> expression E;
> @@
>
> (
> - jiffies <= E
> + time_before_eq(jiffies,E)
> |
> - jiffies >= E
> + time_after_eq(jiffies,E)
> |
> - jiffies < E
> + time_before(jiffies,E)
> |
> - jiffies > E
> + time_after(jiffies,E)
> )
>
> @ include depends on change_compare_np @
> @@
>
> #include
>
> @ no_include depends on !include && change_compare_np @
> @@
>
> #include
> + #include
> //
>
> Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
> ---
>
> diff -r -u -p a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
> --- a/arch/alpha/kernel/traps.c 2007-10-22 11:24:57.0 +0200
> +++ b/arch/alpha/kernel/traps.c 2007-12-23 20:30:39.0 +0100
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -781,7 +782,7 @@ do_entUnaUser(void __user * va, unsigned
> with the unaliged access. */
>
> if (!test_thread_flag (TIF_UAC_NOPRINT)) {
> - if (cnt >= 5 && jiffies - last_time > 5*HZ) {
> + if (cnt >= 5 && time_after(jiffies, last_time + 5*HZ)) {
> cnt = 0;
> }
> if (++cnt < 5) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 4/4] usb: libusual: locking cleanup
On Mon, 2007-12-24 at 06:12 -0800, Pete Zaitcev wrote: > On Sun, 23 Dec 2007 08:46:37 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote: > > > I noticed you also have a spinlock held in usu_probe_thread(), the > > usu_lock.. That spinlock would preclude anything inside request_module() > > from sleeping.. > > The usu_lock is not held across request_module. In fact, it can be > easily taken from inside request_module, when it invokes modprobe. > Stop scaring me :-) Your right, it's just outside .. I still don't think it could deadlock, since I don't see a code path to recursively get back into those libusual functions.. > > One thing that has bothered me is that I don't see a reason why this > > couldn't become a complete, yet you have a comment which says that it > > can't be a complete.. I honestly didn't understand the comment.. I would > > imagine that you tried a complete , and it didn't work? > > Yes, it was a completition initially. But suppose you have two storage > devices, plugged in across a reboot. Two threads are created and have to > wait until the libusual's init function ends. Since we post one > completion, > only one thread continues. Ok .. The mutex should just prevent them from running at the same time, but they should both run eventually. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 7/38] arch/x86/ia32: Use time_before, time_before_eq, etc.
On Mon, 24 Dec 2007, Andi Kleen wrote: > On Mon, Dec 24, 2007 at 03:23:19PM +0100, Julia Lawall wrote: > > From: Julia Lawall <[EMAIL PROTECTED]> > > > > The functions time_before, time_before_eq, time_after, and time_after_eq > > are more robust for comparing jiffies against other values. > > The old code was actually correct I think, but the change is ok for me. Please ignore the patch. All of my before_eq and after_eq's are backwards due to parsing <= as >= and vice versa. I will try again. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] PM: Do not destroy/create devices while suspended
On Mon, 24 Dec 2007, Rafael J. Wysocki wrote: > Hi, > > Some device drivers register CPU hotplug notifiers and use them to destroy > device objects when removing the corresponding CPUs and to create these > objects > when adding the CPUs back. > > Unfortunately, this is not the right thing to do during suspend/hibernation, > since in that cases the CPU hotplug notifiers are called after suspending > devices and before resuming them, so the operations in question are carried > out on the objects representing suspended devices which shouldn't be > unregistered behing the PM core's back. Although right now it usually doesn't > lead to any practical complications, it will predictably deadlock if > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is applied. > > The solution is to prevent drivers from removing/adding devices from within > CPU hotplug notifiers during suspend/hibernation using the FROZEN bit > in the notifier's action argument. The following three patches modify the > MSR, x86-64 MCE and cpuid drivers along these lines. Do we need to worry about the possibility that when the system wakes up from hibernation, the set of usable CPUs might be smaller than it was beforehand? Is any special handling needed for this, or is it already accounted for? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] IDE fixes
[ added Linus to Cc: ]
On Monday 24 December 2007, Bartlomiej Zolnierkiewicz wrote:
>
> cmd64x regression bugfix, few obvious ide-cd fixes from the "redux" patch
> peries and ide-cd MAINTAINERS entry update (Borislav, welcome on board!).
>
> Oh yes, I would forget...
>
> Merry Christmas!
Well, I forgot to send this to Linus instead... :-)
> Linus, please pull from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
>
> to receive the following updates:
>
> MAINTAINERS |4 ++-
> drivers/ide/ide-cd.c | 66 +++--
> drivers/ide/ide-cd.h |3 +-
> drivers/ide/pci/cmd64x.c |4 +-
> drivers/ide/pci/cs5535.c |2 +-
> 5 files changed, 42 insertions(+), 37 deletions(-)
>
>
> Bartlomiej Zolnierkiewicz (10):
> ide-cd: fix SAMSUNG CD-ROM SCR-3231 quirk
> ide-cd: fix ACER/AOpen 24X CDROM speed reporting on big-endian machines
> ide-cd: use ide_cd_release() in ide_cd_probe()
> ide-cd: fix error messages in cdrom_{read,write}_check_ireason()
> ide-cd: add missing 'ireason' masking to cdrom_write_intr()
> ide-cd: fix error messages in cdrom_write_intr()
> ide-cd: add error message for DMA error to cdrom_read_intr()
> ide-cd: fix error message in cdrom_pc_intr()
> ide-cd: fix 'ireason' reporting in cdrom_pc_intr()
> cmd64x: fix hwif->chipset setup
>
> Borislav Petkov (1):
> MAINTAINERS: update ide-cd entry
>
> Joe Perches (1):
> drivers/ide/: Spelling fixes
>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3d567fd..79c711e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1870,8 +1870,10 @@ T: quilt
> kernel.org/pub/linux/kernel/people/bart/pata-2.6/
> S: Maintained
>
> IDE/ATAPI CDROM DRIVER
> +P: Borislav Petkov
> +M: [EMAIL PROTECTED]
> L: [EMAIL PROTECTED]
> -S: Unmaintained
> +S: Maintained
>
> IDE/ATAPI FLOPPY DRIVERS
> P: Paul Bristow
> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index 92ac658..c7d77f0 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -1068,8 +1068,8 @@ int cdrom_read_check_ireason (ide_drive_t *drive, int
> len, int ireason)
> return 0;
> else if (ireason == 0) {
> /* Whoops... The drive is expecting to receive data from us! */
> - printk(KERN_ERR "%s: read_intr: Drive wants to transfer data
> the "
> - "wrong way!\n", drive->name);
> + printk(KERN_ERR "%s: %s: wrong transfer direction!\n",
> + drive->name, __FUNCTION__);
>
> /* Throw some data at the drive so it doesn't hang
> and quit this request. */
> @@ -1086,8 +1086,8 @@ int cdrom_read_check_ireason (ide_drive_t *drive, int
> len, int ireason)
> return 0;
> } else {
> /* Drive wants a command packet, or invalid ireason... */
> - printk(KERN_ERR "%s: read_intr: bad interrupt reason %x\n",
> drive->name,
> - ireason);
> + printk(KERN_ERR "%s: %s: bad interrupt reason 0x%02x\n",
> + drive->name, __FUNCTION__, ireason);
> }
>
> cdrom_end_request(drive, 0);
> @@ -1112,8 +1112,11 @@ static ide_startstop_t cdrom_read_intr (ide_drive_t
> *drive)
>*/
> if (dma) {
> info->dma = 0;
> - if ((dma_error = HWIF(drive)->ide_dma_end(drive)))
> + dma_error = HWIF(drive)->ide_dma_end(drive);
> + if (dma_error) {
> + printk(KERN_ERR "%s: DMA read error\n", drive->name);
> ide_dma_off(drive);
> + }
> }
>
> if (cdrom_decode_status(drive, 0, ))
> @@ -1443,7 +1446,7 @@ static ide_startstop_t cdrom_pc_intr (ide_drive_t
> *drive)
> return ide_stopped;
>
> /* Read the interrupt reason and the transfer length. */
> - ireason = HWIF(drive)->INB(IDE_IREASON_REG);
> + ireason = HWIF(drive)->INB(IDE_IREASON_REG) & 0x3;
> lowcyl = HWIF(drive)->INB(IDE_BCOUNTL_REG);
> highcyl = HWIF(drive)->INB(IDE_BCOUNTH_REG);
>
> @@ -1484,7 +1487,7 @@ static ide_startstop_t cdrom_pc_intr (ide_drive_t
> *drive)
> if (thislen > len) thislen = len;
>
> /* The drive wants to be written to. */
> - if ((ireason & 3) == 0) {
> + if (ireason == 0) {
> if (!rq->data) {
> blk_dump_rq_flags(rq, "cdrom_pc_intr, write");
> goto confused;
> @@ -1506,9 +1509,9 @@ static ide_startstop_t cdrom_pc_intr (ide_drive_t
> *drive)
> }
>
> /* Same drill for reading. */
> - else if ((ireason & 3) == 2) {
> + else if (ireason == 2) {
> if (!rq->data) {
> - blk_dump_rq_flags(rq, "cdrom_pc_intr, write");
> +
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Mon, Dec 24, 2007 at 02:22:10AM -0500, Jeff Garzik wrote:
> The phrase "all or none" specifically describes the current practice in
> arch/x86/pci/mmconfig_{32,64}.c whereby a PCI bus always has one, and only
> one, access method.
>
> So the problems you describe are unrelated to "all or none" as I was
> describing it.
Ok. So a correct description would be "one or another but not both".
>> The mixed access that Loic proposes allows to avoid these boot problems
>> just for free.
>
> False. If you have overlapping areas, then clearly it is board-dependent
> (undefined) what happens -- you might trigger an mmconfig access by
> writel() to your PCI device's MMIO BAR space.
You're not allowed to access MMIO defined by BARs before the PCI setup
process is finished because a) decode of the BAR might be disabled for
a number of reasons and b) the BAR may contain any random value.
So you never know *what* you're accessing until after
pci_assign_unassigned_resources() and without pci_enable_device().
> Consider, too, what the current code in arch/x86/pci/mmconfig_{32,64}.c
> does: it uses the range BIOS told to use for mmconfig, no more no less.
Incorrect. It does reads mcfg info directly from hardware for two Intel
bridges (should be much more - mmconfig BAR is well documented for all
Intel (and AMD, I guess) chipsets.
> Clearly many early mmconfig BIOSes have buggy resource allocation... Thus
> if mmconfig is not known working on a system, turn it off 100% for all
> buses. End of story.
Direct hardware support for more chipsets would certainly help here.
>> Systems that have both non-mmconf PCI(X) and mmconf PCI-E
>> domains could be handled almost for free as well.
>
> The existing code in arch/x86/pci/mmconfig_{32,64}.c today handles mixing
> of PCI-E and PCI-X just fine. As noted above, its done on a per-bus and
> per-segment basis today.
With mixed access unreachable_devices() and related stuff could have gone.
> The proposed API adds code, so I don't see how it simplifies things.
See above.
> The current approach is quite clean anyway:
>
> 1) "raw_pci_ops" points to a single set of PCI config accessors.
> 2) For mmconfig, if the BIOS did not tell us to use mmconfig with a given
> PCI bus, fall back to type1 accesses.
But it doesn't work on systems where [basically working] mmconfig causes
boot problems because it's enabled too early.
> I agree with the function as noted in response to Linus's "Sound ok with
> this plan?" email. But note -- users and developers also need to access
> extended config space, even if driver did not request it. Even if there is
> no driver at all.
There *is* a driver - pci-sysfs.c.
> Otherwise the value of "lspci -vvvxxx" debugging reports from users is
> diminished.
Not at all. I don't see any reason to change the userspace API -
just make pci-sysfs.c:pci_{read,write}_config to request extended space
if (off + count > 256).
Ivan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: Cosmetic fixes fault_{32|64}.c
First step towards unifying these files.
- Checkpatch trailing whitespace fixes
- Checkpatch indentation of switch statement fixes
- Checkpatch single statement ifs need no braces fixes
- Checkpatch consistent spacing after comma fixes
- Introduce defines for pagefault error bits from X86_64 and add useful
comment from X86_32. Use these defines in X86_32 where obvious.
- Unify comments between 32|64 bit
- Small ifdef movement for CONFIG_KPROBES in notify_page_fault()
- Introduce X86_64 only case statement
No Functional Changes.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
arch/x86/mm/fault_32.c | 148 ++-
arch/x86/mm/fault_64.c | 151 ---
2 files changed, 160 insertions(+), 139 deletions(-)
diff --git a/arch/x86/mm/fault_32.c b/arch/x86/mm/fault_32.c
index db8d748..bfb0917 100644
--- a/arch/x86/mm/fault_32.c
+++ b/arch/x86/mm/fault_32.c
@@ -1,6 +1,4 @@
/*
- * linux/arch/i386/mm/fault.c
- *
* Copyright (C) 1995 Linus Torvalds
*/
@@ -30,11 +28,25 @@
#include
#include
-extern void die(const char *,struct pt_regs *,long);
+/*
+ * Page fault error code bits
+ * bit 0 == 0 means no page found, 1 means protection fault
+ * bit 1 == 0 means read, 1 means write
+ * bit 2 == 0 means kernel, 1 means user-mode
+ * bit 3 == 1 means use of reserved bit detected
+ * bit 4 == 1 means fault was an instruction fetch
+ */
+#define PF_PROT(1<<0)
+#define PF_WRITE (1<<1)
+#define PF_USER(1<<2)
+#define PF_RSVD(1<<3)
+#define PF_INSTR (1<<4)
+
+extern void die(const char *, struct pt_regs *, long);
-#ifdef CONFIG_KPROBES
static inline int notify_page_fault(struct pt_regs *regs)
{
+#ifdef CONFIG_KPROBES
int ret = 0;
/* kprobe_running() needs smp_processor_id() */
@@ -46,13 +58,10 @@ static inline int notify_page_fault(struct pt_regs *regs)
}
return ret;
-}
#else
-static inline int notify_page_fault(struct pt_regs *regs)
-{
return 0;
-}
#endif
+}
/*
* Return EIP plus the CS segment base. The segment limit is also
@@ -65,7 +74,7 @@ static inline int notify_page_fault(struct pt_regs *regs)
* If CS is no longer a valid code segment, or if EIP is beyond the
* limit, or if it is a kernel address when CS is not a kernel segment,
* then the returned value will be greater than *eip_limit.
- *
+ *
* This is slow, but is very rarely executed.
*/
static inline unsigned long get_segment_eip(struct pt_regs *regs,
@@ -84,7 +93,7 @@ static inline unsigned long get_segment_eip(struct pt_regs
*regs,
/* The standard kernel/user address space limit. */
*eip_limit = user_mode(regs) ? USER_DS.seg : KERNEL_DS.seg;
-
+
/* By far the most common cases. */
if (likely(SEGMENT_IS_FLAT_CODE(seg)))
return ip;
@@ -99,7 +108,7 @@ static inline unsigned long get_segment_eip(struct pt_regs
*regs,
return 1;/* So that returned ip > *eip_limit. */
}
- /* Get the GDT/LDT descriptor base.
+ /* Get the GDT/LDT descriptor base.
When you look for races in this code remember that
LDT and other horrors are only used in user space. */
if (seg & (1<<2)) {
@@ -109,16 +118,16 @@ static inline unsigned long get_segment_eip(struct
pt_regs *regs,
desc = (void *)desc + (seg & ~7);
} else {
/* Must disable preemption while reading the GDT. */
- desc = (u32 *)get_cpu_gdt_table(get_cpu());
+ desc = (u32 *)get_cpu_gdt_table(get_cpu());
desc = (void *)desc + (seg & ~7);
}
/* Decode the code segment base from the descriptor */
base = get_desc_base((struct desc_struct *)desc);
- if (seg & (1<<2)) {
+ if (seg & (1<<2))
mutex_unlock(>mm->context.lock);
- } else
+ else
put_cpu();
/* Adjust EIP and segment limit, and clamp at the kernel limit.
@@ -129,19 +138,19 @@ static inline unsigned long get_segment_eip(struct
pt_regs *regs,
return ip + base;
}
-/*
+/*
* Sometimes AMD Athlon/Opteron CPUs report invalid exceptions on prefetch.
* Check that here and ignore it.
*/
static int __is_prefetch(struct pt_regs *regs, unsigned long addr)
-{
+{
unsigned long limit;
- unsigned char *instr = (unsigned char *)get_segment_eip (regs, );
+ unsigned char *instr = (unsigned char *)get_segment_eip(regs, );
int scan_more = 1;
- int prefetch = 0;
+ int prefetch = 0;
int i;
- for (i = 0; scan_more && i < 15; i++) {
+ for (i = 0; scan_more && i < 15; i++) {
unsigned char opcode;
unsigned char instr_hi;
unsigned char instr_lo;
@@ -149,27 +158,43 @@ static int __is_prefetch(struct pt_regs *regs, unsigned
long addr)
Re: [PATCH 20/38] drivers/net: Use time_before, time_before_eq, etc.
In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:40:06 +0100 (CET)),
Julia Lawall <[EMAIL PROTECTED]> says:
> diff -r -u -p a/drivers/net/cassini.c b/drivers/net/cassini.c
> --- a/drivers/net/cassini.c 2007-10-22 11:25:14.0 +0200
> +++ b/drivers/net/cassini.c 2007-12-23 20:38:34.0 +0100
> @@ -91,6 +91,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -4141,8 +4142,9 @@ static void cas_link_timer(unsigned long
>
> if (link_transition_timeout != 0 &&
> cp->link_transition_jiffies_valid &&
> - ((jiffies - cp->link_transition_jiffies) >
> - (link_transition_timeout))) {
> + (time_after(jiffies,
> + cp->link_transition_jiffies +
> + (link_transition_timeout {
> /* One-second counter so link-down workaround doesn't
>* cause resets to occur so fast as to fool the switch
>* into thinking the link is down.
> diff -r -u -p a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c
> --- a/drivers/net/cs89x0.c2007-10-22 11:25:14.0 +0200
> +++ b/drivers/net/cs89x0.c2007-12-23 20:38:54.0 +0100
> @@ -450,7 +451,7 @@ wait_eeprom_ready(struct net_device *dev
> just in case EEPROM is ready when SI_BUSY in the
> PP_SelfST is clear */
> while(readreg(dev, PP_SelfST) & SI_BUSY)
> - if (jiffies - timeout >= 40)
> + if (time_before_eq(jiffies, timeout + 40))
> return -1;
> return 0;
> }
time_after_eq().
> @@ -1181,10 +1183,10 @@ send_test_pkt(struct net_device *dev)
:
> break;
> - if (jiffies - timenow >= 5)
> + if (time_before_eq(jiffies, timenow + 5))
> return 0; /* this shouldn't happen */
>
> /* Write the contents of the packet */
time_after_eq()
> diff -r -u -p a/drivers/net/e1000/e1000_ethtool.c
> b/drivers/net/e1000/e1000_ethtool.c
> --- a/drivers/net/e1000/e1000_ethtool.c 2007-12-09 09:35:19.0
> +0100
> +++ b/drivers/net/e1000/e1000_ethtool.c 2007-12-23 20:30:39.0
> +0100
> @@ -1537,12 +1537,12 @@ e1000_run_loopback_test(struct e1000_ada
:
> break;
> }
> - if (jiffies >= (time + 2)) {
> + if (time_before_eq(jiffies, time + 2)) {
> ret_val = 14; /* error code for time out error */
> break;
> }
ditto.
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 7/38] arch/x86/ia32: Use time_before, time_before_eq, etc.
On Mon, Dec 24, 2007 at 03:23:19PM +0100, Julia Lawall wrote: > From: Julia Lawall <[EMAIL PROTECTED]> > > The functions time_before, time_before_eq, time_after, and time_after_eq > are more robust for comparing jiffies against other values. The old code was actually correct I think, but the change is ok for me. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/38] drivers/infiniband: Use time_before, time_before_eq, etc.
On Tue, 25 Dec 2007, YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote:
> In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:28:42 +0100 (CET)),
> Julia Lawall <[EMAIL PROTECTED]> says:
>
> > diff -r -u -p a/drivers/infiniband/hw/ipath/ipath_mad.c
> > b/drivers/infiniband/hw/ipath/ipath_mad.c
> > --- a/drivers/infiniband/hw/ipath/ipath_mad.c 2007-10-22
> > 11:25:09.0 +0200
> > +++ b/drivers/infiniband/hw/ipath/ipath_mad.c 2007-12-23
> > 20:35:37.0 +0100
> > @@ -1334,7 +1334,8 @@ static int process_subn(struct ib_device
> > }
> >
> > /* Is the mkey in the process of expiring? */
> > - if (dev->mkey_lease_timeout && jiffies >= dev->mkey_lease_timeout) {
> > + if (dev->mkey_lease_timeout &&
> > + time_before_eq(jiffies, dev->mkey_lease_timeout)) {
> > /* Clear timeout and mkey protection field. */
> > dev->mkey_lease_timeout = 0;
> > dev->mkeyprot = 0;
>
> time_after_eq()
I see that there are quite a lot of problems like this. I will have to
start over...
julia
Re: [PATCH 15/38] drivers/infiniband: Use time_before, time_before_eq, etc.
In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:28:42 +0100 (CET)),
Julia Lawall <[EMAIL PROTECTED]> says:
> diff -r -u -p a/drivers/infiniband/hw/ipath/ipath_mad.c
> b/drivers/infiniband/hw/ipath/ipath_mad.c
> --- a/drivers/infiniband/hw/ipath/ipath_mad.c 2007-10-22 11:25:09.0
> +0200
> +++ b/drivers/infiniband/hw/ipath/ipath_mad.c 2007-12-23 20:35:37.0
> +0100
> @@ -1334,7 +1334,8 @@ static int process_subn(struct ib_device
> }
>
> /* Is the mkey in the process of expiring? */
> - if (dev->mkey_lease_timeout && jiffies >= dev->mkey_lease_timeout) {
> + if (dev->mkey_lease_timeout &&
> + time_before_eq(jiffies, dev->mkey_lease_timeout)) {
> /* Clear timeout and mkey protection field. */
> dev->mkey_lease_timeout = 0;
> dev->mkeyprot = 0;
time_after_eq()
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/38] arch/ia64/sn: Use time_before, time_before_eq, etc.
In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:18:56 +0100 (CET)),
Julia Lawall <[EMAIL PROTECTED]> says:
> diff -r -u -p a/arch/ia64/sn/kernel/xpc_main.c
> b/arch/ia64/sn/kernel/xpc_main.c
> --- a/arch/ia64/sn/kernel/xpc_main.c 2007-11-12 10:35:56.0 +0100
> +++ b/arch/ia64/sn/kernel/xpc_main.c 2007-12-23 20:32:54.0 +0100
> @@ -230,7 +231,7 @@ xpc_hb_beater(unsigned long dummy)
> {
> xpc_vars->heartbeat++;
>
> - if (jiffies >= xpc_hb_check_timeout) {
> + if (time_before_eq(jiffies, xpc_hb_check_timeout)) {
> wake_up_interruptible(_act_IRQ_wq);
> }
>
time_after_eq()
> @@ -270,7 +271,7 @@ xpc_hb_checker(void *ignore)
>
>
> /* checking of remote heartbeats is skewed by IRQ handling */
> - if (jiffies >= xpc_hb_check_timeout) {
> + if (time_before_eq(jiffies, xpc_hb_check_timeout)) {
> dev_dbg(xpc_part, "checking remote heartbeats\n");
> xpc_check_remote_hb();
>
ditto.
> @@ -305,7 +306,7 @@ xpc_hb_checker(void *ignore)
> /* wait for IRQ or timeout */
> (void) wait_event_interruptible(xpc_act_IRQ_wq,
> (last_IRQ_count < atomic_read(_act_IRQ_rcvd) ||
> - jiffies >= xpc_hb_check_timeout ||
> + time_before_eq(jiffies, xpc_hb_check_timeout) ||
> (volatile int) xpc_exiting));
> }
>
ditto.
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1 - SCSI/blkdev probing hang
On Thu, 20 Dec 2007 13:22:12 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 20 Dec 2007 15:57:45 -0500 > Rik van Riel <[EMAIL PROTECTED]> wrote: > > > 2.6.24-rc5-mm1 seems to have a hang related to the SCSI or block > > device probing code. > It could be a scsi problem, or it could be all the kobject changes in > Greg's driver tree. Or a combination of the two. > > Don't know, sorry. Whatever it was, it's gone now. 2.6.24-rc6-mm1 boots on my system. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 31/38] net/decnet: Use time_before, time_before_eq, etc.
In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:47:32 +0100 (CET)),
Julia Lawall <[EMAIL PROTECTED]> says:
> From: Julia Lawall <[EMAIL PROTECTED]>
>
> The functions time_before, time_before_eq, time_after, and time_after_eq
> are more robust for comparing jiffies against other values.
> - jiffies >= E
> + time_after_eq(jiffies,E)
> diff -r -u -p a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
> --- a/net/decnet/af_decnet.c 2007-11-08 08:00:53.0 +0100
> +++ b/net/decnet/af_decnet.c 2007-12-23 20:30:40.0 +0100
:
> @@ -601,7 +602,7 @@ int dn_destroy_timer(struct sock *sk)
> if (sk->sk_socket)
> return 0;
>
> - if ((jiffies - scp->stamp) >= (HZ * decnet_time_wait)) {
> + if (time_before_eq(jiffies, scp->stamp + HZ * decnet_time_wait)) {
> dn_unhash_sock(sk);
> sock_put(sk);
> return 1;
ugh?
> --- a/net/decnet/dn_timer.c 2006-11-30 19:05:46.0 +0100
> +++ b/net/decnet/dn_timer.c 2007-12-23 20:30:40.0 +0100
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -96,7 +97,7 @@ static void dn_slow_timer(unsigned long
>* since the last successful transmission.
>*/
> if (scp->keepalive && scp->keepalive_fxn && (scp->state == DN_RUN)) {
> - if ((jiffies - scp->stamp) >= scp->keepalive)
> + if (time_before_eq(jiffies, scp->stamp + scp->keepalive))
> scp->keepalive_fxn(sk);
> }
>
ugh?
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 37/38] net/sctp: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/net/sctp/outqueue.c b/net/sctp/outqueue.c
--- a/net/sctp/outqueue.c 2007-11-15 15:09:38.0 +0100
+++ b/net/sctp/outqueue.c 2007-12-23 20:46:36.0 +0100
@@ -50,6 +50,7 @@
#include/* For struct list_head */
#include
#include
+#include
#include /* For skb_set_owner_w */
#include
@@ -425,7 +426,8 @@ void sctp_retransmit_mark(struct sctp_ou
* retransmitting due to T3 timeout.
*/
if (reason == SCTP_RTXR_T3_RTX &&
- (jiffies - chunk->sent_at) < transport->last_rto)
+ time_before(jiffies,
+ chunk->sent_at + transport->last_rto))
continue;
/* RFC 2960 6.2.1 Processing a Received SACK
diff -r -u -p a/net/sctp/transport.c b/net/sctp/transport.c
--- a/net/sctp/transport.c 2007-11-15 15:09:39.0 +0100
+++ b/net/sctp/transport.c 2007-12-23 20:46:58.0 +0100
@@ -50,6 +50,7 @@
#include
#include
+#include
#include
#include
@@ -525,8 +526,9 @@ void sctp_transport_lower_cwnd(struct sc
* congestion indications more than once every window of
* data (or more loosely more than once every round-trip time).
*/
- if ((jiffies - transport->last_time_ecne_reduced) >
- transport->rtt) {
+ if (time_after(jiffies,
+ transport->last_time_ecne_reduced +
+ transport->rtt)) {
transport->ssthresh = max(transport->cwnd/2,
4*transport->asoc->pathmtu);
transport->cwnd = transport->ssthresh;
@@ -543,7 +545,8 @@ void sctp_transport_lower_cwnd(struct sc
* to be done every RTO interval, we do it every hearbeat
* interval.
*/
- if ((jiffies - transport->last_time_used) > transport->rto)
+ if (time_after(jiffies,
+ transport->last_time_used + transport->rto))
transport->cwnd = max(transport->cwnd/2,
4*transport->asoc->pathmtu);
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 38/38] sound: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/sound/drivers/serial-u16550.c b/sound/drivers/serial-u16550.c
--- a/sound/drivers/serial-u16550.c 2007-10-22 11:25:52.0 +0200
+++ b/sound/drivers/serial-u16550.c 2007-12-23 20:30:40.0 +0100
@@ -43,6 +43,7 @@
#include
#include
+#include
#include
@@ -694,7 +695,7 @@ static void snd_uart16550_output_write(s
(uart->adaptor == SNDRV_SERIAL_SOUNDCANVAS ||
uart->adaptor == SNDRV_SERIAL_GENERIC) &&
(uart->prev_out != substream->number ||
-jiffies-lasttime > 3*HZ)) {
+time_after(jiffies, lasttime + 3*HZ))) {
if (snd_uart16550_buffer_can_write(uart, 3)) {
/* Roland Soundcanvas part selection */
diff -r -u -p a/sound/oss/pss.c b/sound/oss/pss.c
--- a/sound/oss/pss.c 2006-11-30 19:05:48.0 +0100
+++ b/sound/oss/pss.c 2007-12-23 20:30:40.0 +0100
@@ -60,6 +60,7 @@
#include
#include
#include
+#include
#include "sound_config.h"
#include "sound_firmware.h"
@@ -271,7 +272,7 @@ static int pss_reset_dsp(pss_confdata *
unsigned long i, limit = jiffies + HZ/10;
outw(0x2000, REG(PSS_CONTROL));
- for (i = 0; i < 32768 && (limit-jiffies >= 0); i++)
+ for (i = 0; i < 32768 && (time_after_eq(jiffies, limit)); i++)
inw(REG(PSS_CONTROL));
outw(0x, REG(PSS_CONTROL));
return 1;
@@ -371,11 +372,11 @@ static int pss_download_boot(pss_confdat
outw(0, REG(PSS_DATA));
limit = jiffies + HZ/10;
- for (i = 0; i < 32768 && (limit - jiffies >= 0); i++)
+ for (i = 0; i < 32768 && (time_after_eq(jiffies, limit)); i++)
val = inw(REG(PSS_STATUS));
limit = jiffies + HZ/10;
- for (i = 0; i < 32768 && (limit-jiffies >= 0); i++)
+ for (i = 0; i < 32768 && (time_after_eq(jiffies, limit)); i++)
{
val = inw(REG(PSS_STATUS));
if (val & 0x4000)
diff -r -u -p a/sound/oss/sb_common.c b/sound/oss/sb_common.c
--- a/sound/oss/sb_common.c 2007-02-09 17:34:30.0 +0100
+++ b/sound/oss/sb_common.c 2007-12-23 20:30:40.0 +0100
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "sound_config.h"
#include "sound_firmware.h"
@@ -97,7 +98,7 @@ int sb_dsp_command(sb_devc * devc, unsig
* loops.
*/
- for (i = 0; i < 50 && (limit-jiffies)>0; i++)
+ for (i = 0; i < 50 && time_before(jiffies, limit); i++)
{
if ((inb(DSP_STATUS) & 0x80) == 0)
{
diff -r -u -p a/sound/soc/s3c24xx/s3c24xx-i2s.c
b/sound/soc/s3c24xx/s3c24xx-i2s.c
--- a/sound/soc/s3c24xx/s3c24xx-i2s.c 2007-10-22 11:25:53.0 +0200
+++ b/sound/soc/s3c24xx/s3c24xx-i2s.c 2007-12-23 20:30:40.0 +0100
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -184,7 +185,7 @@ static int s3c24xx_snd_lrsync(void)
if (iiscon & S3C2410_IISCON_LRINDEX)
break;
- if (timeout < jiffies)
+ if (time_after(jiffies, timeout))
return -ETIMEDOUT;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 36/38] net/mac80211: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/net/mac80211/rc80211_simple.c b/net/mac80211/rc80211_simple.c
--- a/net/mac80211/rc80211_simple.c 2007-11-13 16:01:34.0 +0100
+++ b/net/mac80211/rc80211_simple.c 2007-12-23 20:30:40.0 +0100
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include "ieee80211_i.h"
@@ -194,7 +195,7 @@ static void rate_control_simple_tx_statu
rate_control_rate_dec(local, sta);
}
- if (srctrl->avg_rate_update + 60 * HZ < jiffies) {
+ if (time_after(jiffies, srctrl->avg_rate_update + 60 * HZ)) {
srctrl->avg_rate_update = jiffies;
if (srctrl->tx_avg_rate_num > 0) {
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
diff -r -u -p a/net/mac80211/rx.c b/net/mac80211/rx.c
--- a/net/mac80211/rx.c 2007-12-04 13:19:55.0 +0100
+++ b/net/mac80211/rx.c 2007-12-23 20:30:40.0 +0100
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -741,7 +742,7 @@ ieee80211_reassemble_find(struct ieee802
compare_ether_addr(hdr->addr2, f_hdr->addr2) != 0)
continue;
- if (entry->first_frag_time + 2 * HZ < jiffies) {
+ if (time_after(jiffies, entry->first_frag_time + 2 * HZ)) {
__skb_queue_purge(>skb_list);
continue;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 34/38] net/ipv6: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/net/ipv6/sit.c b/net/ipv6/sit.c
--- a/net/ipv6/sit.c2007-11-01 10:30:45.0 +0100
+++ b/net/ipv6/sit.c2007-12-23 20:46:01.0 +0100
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -263,7 +264,7 @@ static int ipip6_err(struct sk_buff *skb
if (t->parms.iph.ttl == 0 && type == ICMP_TIME_EXCEEDED)
goto out;
- if (jiffies - t->err_time < IPTUNNEL_ERR_TIMEO)
+ if (time_before(jiffies, t->err_time + IPTUNNEL_ERR_TIMEO))
t->err_count++;
else
t->err_count = 1;
@@ -520,7 +521,8 @@ static int ipip6_tunnel_xmit(struct sk_b
}
if (tunnel->err_count > 0) {
- if (jiffies - tunnel->err_time < IPTUNNEL_ERR_TIMEO) {
+ if (time_before(jiffies,
+ tunnel->err_time + IPTUNNEL_ERR_TIMEO)) {
tunnel->err_count--;
dst_link_failure(skb);
} else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 35/38] net/irda: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/net/irda/discovery.c b/net/irda/discovery.c
--- a/net/irda/discovery.c 2007-10-22 11:25:46.0 +0200
+++ b/net/irda/discovery.c 2007-12-23 20:46:19.0 +0100
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -170,7 +171,8 @@ void irlmp_expire_discoveries(hashbin_t
/* Test if it's time to expire this discovery */
if ((curr->data.saddr == saddr) &&
(force ||
-((jiffies - curr->timestamp) > DISCOVERY_EXPIRE_TIMEOUT)))
+(time_after(jiffies,
+curr->timestamp + DISCOVERY_EXPIRE_TIMEOUT
{
/* Create buffer as needed.
* As this function get called a lot and most time
@@ -283,7 +285,8 @@ struct irda_device_info *irlmp_copy_disc
* the most recent one (unless we want old ones) */
if ((u16ho(discovery->data.hints) & mask) &&
((old_entries) ||
-((jiffies - discovery->firststamp) < j_timeout)) ) {
+(time_before(jiffies,
+ discovery->firststamp + j_timeout))) ) {
/* Create buffer as needed.
* As this function get called a lot and most time
* we don't have anything to put in the log (we are
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 31/38] net/decnet: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
--- a/net/decnet/af_decnet.c2007-11-08 08:00:53.0 +0100
+++ b/net/decnet/af_decnet.c2007-12-23 20:30:40.0 +0100
@@ -128,6 +128,7 @@ Version 0.0.62.1.110 07-aug-98 E
#include
#include
#include
+#include
#include
#include
#include
@@ -601,7 +602,7 @@ int dn_destroy_timer(struct sock *sk)
if (sk->sk_socket)
return 0;
- if ((jiffies - scp->stamp) >= (HZ * decnet_time_wait)) {
+ if (time_before_eq(jiffies, scp->stamp + HZ * decnet_time_wait)) {
dn_unhash_sock(sk);
sock_put(sk);
return 1;
diff -r -u -p a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c
--- a/net/decnet/dn_dev.c 2007-12-04 13:19:55.0 +0100
+++ b/net/decnet/dn_dev.c 2007-12-23 20:30:40.0 +0100
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -926,7 +927,7 @@ static void dn_send_endnode_hello(struct
static int dn_am_i_a_router(struct dn_neigh *dn, struct dn_dev *dn_db, struct
dn_ifaddr *ifa)
{
/* First check time since device went up */
- if ((jiffies - dn_db->uptime) < DRDELAY)
+ if (time_before(jiffies, dn_db->uptime + DRDELAY))
return 0;
/* If there is no router, then yes... */
diff -r -u -p a/net/decnet/dn_nsp_out.c b/net/decnet/dn_nsp_out.c
--- a/net/decnet/dn_nsp_out.c 2007-06-02 22:32:45.0 +0200
+++ b/net/decnet/dn_nsp_out.c 2007-12-23 20:30:40.0 +0100
@@ -61,6 +61,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -364,7 +365,7 @@ void dn_nsp_queue_xmit(struct sock *sk,
* Slow start: If we have been idle for more than
* one RTT, then reset window to min size.
*/
- if ((jiffies - scp->stamp) > t)
+ if (time_after(jiffies, scp->stamp + t))
scp->snd_window = NSP_MIN_WINDOW;
if (oth)
diff -r -u -p a/net/decnet/dn_route.c b/net/decnet/dn_route.c
--- a/net/decnet/dn_route.c 2007-11-13 16:01:33.0 +0100
+++ b/net/decnet/dn_route.c 2007-12-23 20:30:40.0 +0100
@@ -76,6 +76,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -178,7 +179,7 @@ static void dn_dst_check_expire(unsigned
}
spin_unlock(_rt_hash_table[i].lock);
- if ((jiffies - now) > 0)
+ if (time_after(jiffies, now))
break;
}
diff -r -u -p a/net/decnet/dn_timer.c b/net/decnet/dn_timer.c
--- a/net/decnet/dn_timer.c 2006-11-30 19:05:46.0 +0100
+++ b/net/decnet/dn_timer.c 2007-12-23 20:30:40.0 +0100
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,7 +97,7 @@ static void dn_slow_timer(unsigned long
* since the last successful transmission.
*/
if (scp->keepalive && scp->keepalive_fxn && (scp->state == DN_RUN)) {
- if ((jiffies - scp->stamp) >= scp->keepalive)
+ if (time_before_eq(jiffies, scp->stamp + scp->keepalive))
scp->keepalive_fxn(sk);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 32/38] net/econet: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/net/econet/af_econet.c b/net/econet/af_econet.c
--- a/net/econet/af_econet.c2007-11-08 08:00:53.0 +0100
+++ b/net/econet/af_econet.c2007-12-23 20:30:40.0 +0100
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -993,7 +994,7 @@ static void ab_cleanup(unsigned long h)
{
struct sk_buff *newskb = skb->next;
struct ec_cb *eb = (struct ec_cb *)>cb;
- if ((jiffies - eb->start) > eb->timeout)
+ if (time_after(jiffies, eb->start + eb->timeout))
{
tx_result(skb->sk, eb->cookie,
ECTYPE_TRANSMIT_NOT_PRESENT);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 33/38] net/ipv4: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
--- a/net/ipv4/ip_gre.c 2007-11-01 10:30:44.0 +0100
+++ b/net/ipv4/ip_gre.c 2007-12-23 20:44:52.0 +0100
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -373,7 +374,7 @@ static void ipgre_err(struct sk_buff *sk
if (t->parms.iph.ttl == 0 && type == ICMP_TIME_EXCEEDED)
goto out;
- if (jiffies - t->err_time < IPTUNNEL_ERR_TIMEO)
+ if (time_before(jiffies, t->err_time + IPTUNNEL_ERR_TIMEO))
t->err_count++;
else
t->err_count = 1;
@@ -799,7 +800,8 @@ static int ipgre_tunnel_xmit(struct sk_b
#endif
if (tunnel->err_count > 0) {
- if (jiffies - tunnel->err_time < IPTUNNEL_ERR_TIMEO) {
+ if (time_before(jiffies,
+ tunnel->err_time + IPTUNNEL_ERR_TIMEO)) {
tunnel->err_count--;
dst_link_failure(skb);
diff -r -u -p a/net/ipv4/ipip.c b/net/ipv4/ipip.c
--- a/net/ipv4/ipip.c 2007-11-01 10:30:44.0 +0100
+++ b/net/ipv4/ipip.c 2007-12-23 20:45:06.0 +0100
@@ -108,6 +108,7 @@
#include
#include
#include
+#include
#include
#include
@@ -317,7 +318,7 @@ static int ipip_err(struct sk_buff *skb,
if (t->parms.iph.ttl == 0 && type == ICMP_TIME_EXCEEDED)
goto out;
- if (jiffies - t->err_time < IPTUNNEL_ERR_TIMEO)
+ if (time_before(jiffies, t->err_time + IPTUNNEL_ERR_TIMEO))
t->err_count++;
else
t->err_count = 1;
@@ -582,7 +583,8 @@ static int ipip_tunnel_xmit(struct sk_bu
}
if (tunnel->err_count > 0) {
- if (jiffies - tunnel->err_time < IPTUNNEL_ERR_TIMEO) {
+ if (time_before(jiffies,
+ tunnel->err_time + IPTUNNEL_ERR_TIMEO)) {
tunnel->err_count--;
dst_link_failure(skb);
} else
diff -r -u -p a/net/ipv4/ipvs/ip_vs_lblcr.c b/net/ipv4/ipvs/ip_vs_lblcr.c
--- a/net/ipv4/ipvs/ip_vs_lblcr.c 2007-12-09 09:35:20.0 +0100
+++ b/net/ipv4/ipvs/ip_vs_lblcr.c 2007-12-23 20:45:42.0 +0100
@@ -733,7 +733,8 @@ ip_vs_lblcr_schedule(struct ip_vs_servic
ip_vs_dest_set_insert(>set, dest);
}
if (atomic_read(>set.size) > 1 &&
- jiffies-en->set.lastmod > sysctl_ip_vs_lblcr_expiration) {
+ time_after(jiffies,
+ en->set.lastmod+sysctl_ip_vs_lblcr_expiration)){
struct ip_vs_dest *m;
m = ip_vs_dest_set_max(>set);
if (m)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 29/38] net/bluetooth: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
--- a/net/bluetooth/hci_core.c 2007-11-01 10:30:44.0 +0100
+++ b/net/bluetooth/hci_core.c 2007-12-23 20:44:22.0 +0100
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1321,7 +1322,8 @@ static inline void hci_sched_acl(struct
if (!test_bit(HCI_RAW, >flags)) {
/* ACL tx timeout must be longer than maximum
* link supervision timeout (40.9 seconds) */
- if (!hdev->acl_cnt && (jiffies - hdev->acl_last_tx) > (HZ * 45))
+ if (!hdev->acl_cnt &&
+ time_after(jiffies, hdev->acl_last_tx + HZ * 45))
hci_acl_tx_to(hdev);
}
@@ -1543,7 +1545,8 @@ static void hci_cmd_task(unsigned long a
BT_DBG("%s cmd %d", hdev->name, atomic_read(>cmd_cnt));
- if (!atomic_read(>cmd_cnt) && (jiffies - hdev->cmd_last_tx) > HZ)
{
+ if (!atomic_read(>cmd_cnt) &&
+ time_after(jiffies, hdev->cmd_last_tx + HZ)) {
BT_ERR("%s command tx timeout", hdev->name);
atomic_set(>cmd_cnt, 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/
[PATCH 30/38] net/bridge: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
--- a/net/bridge/br_netfilter.c 2007-11-15 15:09:37.0 +0100
+++ b/net/bridge/br_netfilter.c 2007-12-23 20:30:40.0 +0100
@@ -46,6 +46,7 @@
#include "br_private.h"
#ifdef CONFIG_SYSCTL
#include
+#include
#endif
#define skb_origaddr(skb) (((struct bridge_skb_cb *) \
@@ -221,7 +222,7 @@ static void __br_dnat_complain(void)
{
static unsigned long last_complaint;
- if (jiffies - last_complaint >= 5 * HZ) {
+ if (time_before_eq(jiffies, last_complaint + 5 * HZ)) {
printk(KERN_WARNING "Performing cross-bridge DNAT requires IP "
"forwarding to be enabled\n");
last_complaint = jiffies;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 27/38] kernel: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]> The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. A simplified version of the semantic patch making this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // @ change_compare_np @ expression E; @@ ( - jiffies <= E + time_before_eq(jiffies,E) | - jiffies >= E + time_after_eq(jiffies,E) | - jiffies < E + time_before(jiffies,E) | - jiffies > E + time_after(jiffies,E) ) @ include depends on change_compare_np @ @@ #include @ no_include depends on !include && change_compare_np @ @@ #include + #include // Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> --- diff -r -u -p a/kernel/irq/spurious.c b/kernel/irq/spurious.c --- a/kernel/irq/spurious.c 2007-07-20 17:46:05.0 +0200 +++ b/kernel/irq/spurious.c 2007-12-23 20:30:40.0 +0100 @@ -10,6 +10,7 @@ #include #include #include +#include static int irqfixup __read_mostly; @@ -178,7 +179,7 @@ void note_interrupt(unsigned int irq, st * otherwise the couter becomes a doomsday timer for otherwise * working systems */ - if (jiffies - desc->last_unhandled > HZ/10) + if (time_after(jiffies, desc->last_unhandled + HZ/10)) desc->irqs_unhandled = 1; else desc->irqs_unhandled++; diff -r -u -p a/kernel/timer.c b/kernel/timer.c --- a/kernel/timer.c2007-12-21 06:57:20.0 +0100 +++ b/kernel/timer.c2007-12-23 20:30:40.0 +0100 @@ -165,7 +165,7 @@ unsigned long __round_jiffies(unsigned l /* now that we have rounded, subtract the extra skew again */ j -= cpu * 3; - if (j <= jiffies) /* rounding ate our timeout entirely; */ + if (time_before_eq(jiffies, j))/* rounding ate our timeout entirely; */ return original; return j; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 28/38] mm: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c 2007-12-21 06:57:20.0 +0100
+++ b/mm/page_alloc.c 2007-12-23 20:30:40.0 +0100
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1276,7 +1277,7 @@ static nodemask_t *zlc_setup(struct zone
if (!zlc)
return NULL;
- if (jiffies - zlc->last_full_zap > 1 * HZ) {
+ if (time_after(jiffies, zlc->last_full_zap + 1 * HZ)) {
bitmap_zero(zlc->fullzones, MAX_ZONES_PER_ZONELIST);
zlc->last_full_zap = jiffies;
}
diff -r -u -p a/mm/pdflush.c b/mm/pdflush.c
--- a/mm/pdflush.c 2007-07-20 17:46:05.0 +0200
+++ b/mm/pdflush.c 2007-12-23 20:30:40.0 +0100
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/*
@@ -130,7 +131,7 @@ static int __pdflush(struct pdflush_work
* Thread creation: For how long have there been zero
* available threads?
*/
- if (jiffies - last_empty_jifs > 1 * HZ) {
+ if (time_after(jiffies, last_empty_jifs + 1 * HZ)) {
/* unlocked list_empty() test is OK here */
if (list_empty(_list)) {
/* unlocked test is OK here */
@@ -151,7 +152,7 @@ static int __pdflush(struct pdflush_work
if (nr_pdflush_threads <= MIN_PDFLUSH_THREADS)
continue;
pdf = list_entry(pdflush_list.prev, struct pdflush_work, list);
- if (jiffies - pdf->when_i_went_to_sleep > 1 * HZ) {
+ if (time_after(jiffies, pdf->when_i_went_to_sleep + 1 * HZ)) {
/* Limit exit rate */
pdf->when_i_went_to_sleep = jiffies;
break; /* exeunt */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 25/38] fs: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/fs/binfmt_aout.c b/fs/binfmt_aout.c
--- a/fs/binfmt_aout.c 2007-12-21 06:57:19.0 +0100
+++ b/fs/binfmt_aout.c 2007-12-23 20:42:57.0 +0100
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -373,14 +374,15 @@ static int load_aout_binary(struct linux
} else {
static unsigned long error_time, error_time2;
if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
- (N_MAGIC(ex) != NMAGIC) && (jiffies-error_time2) > 5*HZ)
+ (N_MAGIC(ex) != NMAGIC) &&
+ time_after(jiffies, error_time2 + 5*HZ))
{
printk(KERN_NOTICE "executable not page aligned\n");
error_time2 = jiffies;
}
if ((fd_offset & ~PAGE_MASK) != 0 &&
- (jiffies-error_time) > 5*HZ)
+ time_after(jiffies, error_time + 5*HZ))
{
printk(KERN_WARNING
"fd_offset is not page aligned. Please convert
program: %s\n",
@@ -497,7 +499,7 @@ static int load_aout_library(struct file
static unsigned long error_time;
loff_t pos = N_TXTOFF(ex);
- if ((jiffies-error_time) > 5*HZ)
+ if (time_after(jiffies, error_time + 5*HZ))
{
printk(KERN_WARNING
"N_TXTOFF is not page aligned. Please convert
library: %s\n",
diff -r -u -p a/fs/ncpfs/dir.c b/fs/ncpfs/dir.c
--- a/fs/ncpfs/dir.c2007-06-02 22:32:35.0 +0200
+++ b/fs/ncpfs/dir.c2007-12-23 20:43:19.0 +0100
@@ -23,6 +23,7 @@
#include
#include
+#include
#include "ncplib_kernel.h"
@@ -447,7 +448,8 @@ static int ncp_readdir(struct file *filp
goto init_cache;
if (filp->f_pos == 2) {
- if (jiffies - ctl.head.time >= NCP_MAX_AGE(server))
+ if (time_before_eq(jiffies,
+ ctl.head.time + NCP_MAX_AGE(server)))
goto init_cache;
mtime = ncp_obtain_mtime(dentry);
diff -r -u -p a/fs/smbfs/dir.c b/fs/smbfs/dir.c
--- a/fs/smbfs/dir.c2007-06-02 22:32:36.0 +0200
+++ b/fs/smbfs/dir.c2007-12-23 20:43:34.0 +0100
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "smb_debug.h"
#include "proto.h"
@@ -131,7 +132,7 @@ smb_readdir(struct file *filp, void *dir
}
if (filp->f_pos == 2) {
- if (jiffies - ctl.head.time >= SMB_MAX_AGE(server))
+ if (time_before_eq(jiffies, ctl.head.time+SMB_MAX_AGE(server)))
goto init_cache;
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 26/38] init: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/init/calibrate.c b/init/calibrate.c
--- a/init/calibrate.c 2007-10-22 11:25:44.0 +0200
+++ b/init/calibrate.c 2007-12-23 20:44:00.0 +0100
@@ -65,7 +65,7 @@ static unsigned long __devinit calibrate
pre_start = 0;
read_current_timer();
start_jiffies = jiffies;
- while (jiffies <= (start_jiffies + 1)) {
+ while (time_after_eq(jiffies, start_jiffies + 1)) {
pre_start = start;
read_current_timer();
}
@@ -73,8 +73,9 @@ static unsigned long __devinit calibrate
pre_end = 0;
end = post_start;
- while (jiffies <=
- (start_jiffies + 1 + DELAY_CALIBRATION_TICKS)) {
+ while (time_after_eq(jiffies,
+start_jiffies +
+1 + DELAY_CALIBRATION_TICKS)) {
pre_end = end;
read_current_timer();
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 23/38] usb/serial: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
--- a/drivers/usb/serial/io_ti.c2007-07-23 11:27:17.0 +0200
+++ b/drivers/usb/serial/io_ti.c2007-12-23 20:30:39.0 +0100
@@ -639,7 +639,7 @@ static void TIChasePort(struct edgeport_
/* wait for data to drain from the device */
timeout += jiffies;
- while ((long)(jiffies - timeout) < 0 && !signal_pending(current)
+ while (time_before(jiffies, timeout) && !signal_pending(current)
&& usb_get_intfdata(port->port->serial->interface)) { /* not
disconnected */
if (!TIIsTxActive(port))
break;
diff -r -u -p a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
--- a/drivers/usb/serial/ti_usb_3410_5052.c 2007-10-22 11:25:25.0
+0200
+++ b/drivers/usb/serial/ti_usb_3410_5052.c 2007-12-23 20:30:39.0
+0100
@@ -84,6 +84,7 @@
#include
#include
#include
+#include
#include "ti_usb_3410_5052.h"
#include "ti_fw_3410.h"/* firmware image for 3410 */
@@ -1531,7 +1532,7 @@ static void ti_drain(struct ti_port *tpo
/* wait for empty tx register, plus 20 ms */
timeout += jiffies;
tport->tp_lsr &= ~TI_LSR_TX_EMPTY;
- while ((long)(jiffies - timeout) < 0 && !signal_pending(current)
+ while (time_before(jiffies, timeout) && !signal_pending(current)
&& !(tport->tp_lsr_LSR_TX_EMPTY) && !tdev->td_urb_error
&& usb_get_intfdata(port->serial->interface)) { /* not disconnected */
if (ti_get_lsr(tport))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 24/38] fs/autofs: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]> The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. A simplified version of the semantic patch making this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // @ change_compare_np @ expression E; @@ ( - jiffies <= E + time_before_eq(jiffies,E) | - jiffies >= E + time_after_eq(jiffies,E) | - jiffies < E + time_before(jiffies,E) | - jiffies > E + time_after(jiffies,E) ) @ include depends on change_compare_np @ @@ #include @ no_include depends on !include && change_compare_np @ @@ #include + #include // Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> --- diff -r -u -p a/fs/autofs/dirhash.c b/fs/autofs/dirhash.c --- a/fs/autofs/dirhash.c 2006-11-30 19:05:26.0 +0100 +++ b/fs/autofs/dirhash.c 2007-12-23 20:30:39.0 +0100 @@ -47,7 +47,7 @@ struct autofs_dir_ent *autofs_expire(str return NULL;/* No entries */ /* We keep the list sorted by last_usage and want old stuff */ ent = list_entry(dh->expiry_head.next, struct autofs_dir_ent, exp); - if (jiffies - ent->last_usage < timeout) + if (time_before(jiffies, ent->last_usage + timeout)) break; /* Move to end of list in case expiry isn't desirable */ autofs_update_usage(dh, ent); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 21/38] drivers/scsi: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/scsi/eata.c b/drivers/scsi/eata.c
--- a/drivers/scsi/eata.c 2007-10-22 11:25:23.0 +0200
+++ b/drivers/scsi/eata.c 2007-12-23 20:30:39.0 +0100
@@ -928,6 +928,7 @@ static char boot_options[MAX_BOOT_OPTION
#if defined(MODULE)
#include
#include
+#include
module_param_string(eata, boot_options, MAX_BOOT_OPTIONS_SIZE, 0);
MODULE_PARM_DESC(eata, " equivalent to the \"eata=...\" kernel boot option."
@@ -1996,7 +1997,7 @@ static int eata2x_eh_host_reset(struct s
/* FIXME: use a sleep instead */
time = jiffies;
- while ((jiffies - time) < (10 * HZ) && limit++ < 20)
+ while (time_before(jiffies, time + 10 * HZ) && limit++ < 20)
udelay(100L);
spin_lock_irq(shost->host_lock);
diff -r -u -p a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
--- a/drivers/scsi/lpfc/lpfc_scsi.c 2007-11-08 08:00:52.0 +0100
+++ b/drivers/scsi/lpfc/lpfc_scsi.c 2007-12-23 20:41:54.0 +0100
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -55,7 +56,8 @@ lpfc_adjust_queue_depth(struct lpfc_hba
atomic_inc(>num_rsrc_err);
phba->last_rsrc_error_time = jiffies;
- if ((phba->last_ramp_down_time + QUEUE_RAMP_DOWN_INTERVAL) > jiffies) {
+ if (time_before(jiffies,
+ phba->last_ramp_down_time + QUEUE_RAMP_DOWN_INTERVAL)){
spin_unlock_irqrestore(>hbalock, flags);
return;
}
@@ -94,8 +96,10 @@ lpfc_rampup_queue_depth(struct lpfc_vpor
if (vport->cfg_lun_queue_depth <= sdev->queue_depth)
return;
spin_lock_irqsave(>hbalock, flags);
- if (((phba->last_ramp_up_time + QUEUE_RAMP_UP_INTERVAL) > jiffies) ||
-((phba->last_rsrc_error_time + QUEUE_RAMP_UP_INTERVAL ) > jiffies)) {
+ if ((time_before(jiffies,
+phba->last_ramp_up_time + QUEUE_RAMP_UP_INTERVAL)) ||
+(time_before(jiffies,
+ phba->last_rsrc_error_time + QUEUE_RAMP_UP_INTERVAL))) {
spin_unlock_irqrestore(>hbalock, flags);
return;
}
@@ -617,10 +621,12 @@ lpfc_scsi_cmd_iocb_cmpl(struct lpfc_hba
lpfc_rampup_queue_depth(vport, sdev);
if (!result && pnode != NULL &&
- ((jiffies - pnode->last_ramp_up_time) >
- LPFC_Q_RAMP_UP_INTERVAL * HZ) &&
- ((jiffies - pnode->last_q_full_time) >
- LPFC_Q_RAMP_UP_INTERVAL * HZ) &&
+ (time_after(jiffies,
+ pnode->last_ramp_up_time +
+ LPFC_Q_RAMP_UP_INTERVAL * HZ)) &&
+ (time_after(jiffies,
+ pnode->last_q_full_time +
+ LPFC_Q_RAMP_UP_INTERVAL * HZ)) &&
(vport->cfg_lun_queue_depth > sdev->queue_depth)) {
shost_for_each_device(tmp_sdev, sdev->host) {
if (vport->cfg_lun_queue_depth > tmp_sdev->queue_depth){
diff -r -u -p a/drivers/scsi/u14-34f.c b/drivers/scsi/u14-34f.c
--- a/drivers/scsi/u14-34f.c2007-10-22 11:25:24.0 +0200
+++ b/drivers/scsi/u14-34f.c2007-12-23 20:42:31.0 +0100
@@ -673,6 +673,7 @@ static char boot_options[MAX_BOOT_OPTION
#if defined(MODULE)
#include
#include
+#include
module_param_string(u14_34f, boot_options, MAX_BOOT_OPTIONS_SIZE, 0);
MODULE_PARM_DESC(u14_34f, " equivalent to the \"u14-34f=...\" kernel boot " \
@@ -778,7 +779,7 @@ static int board_inquiry(unsigned int j)
spin_unlock_irq(_lock);
time = jiffies;
- while ((jiffies - time) < HZ && limit++ < 2) udelay(100L);
+ while (time_before(jiffies, time + HZ) && limit++ < 2) udelay(100L);
spin_lock_irq(_lock);
if (cpp->adapter_status || HD(j)->cp_stat[0] != FREE) {
@@ -1479,7 +1480,8 @@ static int u14_34f_eh_host_reset(struct
spin_unlock_irq(sh[j]->host_lock);
time = jiffies;
- while ((jiffies - time) < (10 * HZ) && limit++ < 20) udelay(100L);
+ while (time_before(jiffies, time + 10 * HZ) && limit++ < 20)
+ udelay(100L);
spin_lock_irq(sh[j]->host_lock);
printk("%s: reset, interrupts disabled, loops %d.\n", BN(j), limit);
--
To unsubscribe from this list: send
[PATCH 22/38] serial: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]> The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. A simplified version of the semantic patch making this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // @ change_compare_np @ expression E; @@ ( - jiffies <= E + time_before_eq(jiffies,E) | - jiffies >= E + time_after_eq(jiffies,E) | - jiffies < E + time_before(jiffies,E) | - jiffies > E + time_after(jiffies,E) ) @ include depends on change_compare_np @ @@ #include @ no_include depends on !include && change_compare_np @ @@ #include + #include // Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> --- diff -r -u -p a/drivers/serial/68360serial.c b/drivers/serial/68360serial.c --- a/drivers/serial/68360serial.c 2007-07-20 17:45:57.0 +0200 +++ b/drivers/serial/68360serial.c 2007-12-23 20:30:39.0 +0100 @@ -51,6 +51,7 @@ extern int kgdb_output_string (const ch /* #ifdef CONFIG_SERIAL_CONSOLE */ /* This seems to be a post 2.0 thing - mles */ #include +#include /* this defines the index into rs_table for the port to use */ @@ -1729,7 +1730,7 @@ static void rs_360_wait_until_sent(struc msleep_interruptible(jiffies_to_msecs(char_time)); if (signal_pending(current)) break; - if (timeout && ((orig_jiffies + timeout) < jiffies)) + if (timeout && (time_after(jiffies, orig_jiffies + timeout))) break; /* The 'tx_cur' is really the next buffer to send. We * have to back up to the previous BD and wait for 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/
[PATCH 20/38] drivers/net: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c
--- a/drivers/net/arcnet/arcnet.c 2007-10-22 11:25:13.0 +0200
+++ b/drivers/net/arcnet/arcnet.c 2007-12-23 20:38:12.0 +0100
@@ -940,7 +940,7 @@ irqreturn_t arcnet_interrupt(int irq, vo
/* is the RECON info empty or old? */
if (!lp->first_recon || !lp->last_recon ||
- jiffies - lp->last_recon > HZ * 10) {
+ time_after(jiffies, lp->last_recon + HZ * 10)) {
if (lp->network_down)
BUGMSG(D_NORMAL, "reconfiguration
detected: cabling restored?\n");
lp->first_recon = lp->last_recon = jiffies;
@@ -974,7 +974,8 @@ irqreturn_t arcnet_interrupt(int irq, vo
lp->num_recons = 1;
}
}
- } else if (lp->network_down && jiffies - lp->last_recon > HZ *
10) {
+ } else if (lp->network_down &&
+ time_after(jiffies, lp->last_recon + HZ * 10)) {
if (lp->network_down)
BUGMSG(D_NORMAL, "cabling restored?\n");
lp->first_recon = lp->last_recon = 0;
diff -r -u -p a/drivers/net/ax88796.c b/drivers/net/ax88796.c
--- a/drivers/net/ax88796.c 2007-10-22 11:25:13.0 +0200
+++ b/drivers/net/ax88796.c 2007-12-23 20:30:39.0 +0100
@@ -150,7 +150,7 @@ static void ax_reset_8390(struct net_dev
/* This check _should_not_ be necessary, omit eventually. */
while ((ei_inb(addr + EN0_ISR) & ENISR_RESET) == 0) {
- if (jiffies - reset_start_time > 2*HZ/100) {
+ if (time_after(jiffies, reset_start_time + 2*HZ/100)) {
printk(KERN_WARNING "%s: %s did not complete.\n",
__FUNCTION__, dev->name);
break;
@@ -280,7 +280,7 @@ static void ax_block_output(struct net_d
dma_start = jiffies;
while ((ei_inb(nic_base + EN0_ISR) & ENISR_RDC) == 0) {
- if (jiffies - dma_start > 2*HZ/100) { /* 20ms */
+ if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
printk(KERN_WARNING "%s: timeout waiting for Tx
RDC.\n", dev->name);
ax_reset_8390(dev);
ax_NS8390_init(dev,1);
diff -r -u -p a/drivers/net/cassini.c b/drivers/net/cassini.c
--- a/drivers/net/cassini.c 2007-10-22 11:25:14.0 +0200
+++ b/drivers/net/cassini.c 2007-12-23 20:38:34.0 +0100
@@ -91,6 +91,7 @@
#include
#include
#include
+#include
#include
@@ -4141,8 +4142,9 @@ static void cas_link_timer(unsigned long
if (link_transition_timeout != 0 &&
cp->link_transition_jiffies_valid &&
- ((jiffies - cp->link_transition_jiffies) >
- (link_transition_timeout))) {
+ (time_after(jiffies,
+ cp->link_transition_jiffies +
+ (link_transition_timeout {
/* One-second counter so link-down workaround doesn't
* cause resets to occur so fast as to fool the switch
* into thinking the link is down.
diff -r -u -p a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c
--- a/drivers/net/cs89x0.c 2007-10-22 11:25:14.0 +0200
+++ b/drivers/net/cs89x0.c 2007-12-23 20:38:54.0 +0100
@@ -145,6 +145,7 @@
#include
#include
#include
+#include
#include
#include
@@ -450,7 +451,7 @@ wait_eeprom_ready(struct net_device *dev
just in case EEPROM is ready when SI_BUSY in the
PP_SelfST is clear */
while(readreg(dev, PP_SelfST) & SI_BUSY)
- if (jiffies - timeout >= 40)
+ if (time_before_eq(jiffies, timeout + 40))
return -1;
return 0;
}
@@ -1055,7 +1056,8 @@ void __init reset_chip(struct net_devic
/* Wait until the chip is reset */
reset_start_time = jiffies;
- while( (readreg(dev, PP_SelfST) & INIT_DONE) == 0 && jiffies -
[PATCH 18/38] drivers/media/video: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/media/video/c-qcam.c b/drivers/media/video/c-qcam.c
--- a/drivers/media/video/c-qcam.c 2007-11-01 10:30:39.0 +0100
+++ b/drivers/media/video/c-qcam.c 2007-12-23 20:36:52.0 +0100
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
@@ -95,7 +96,8 @@ static unsigned int qcam_await_ready1(st
unsigned long oldjiffies = jiffies;
unsigned int i;
- for (oldjiffies = jiffies; (jiffies - oldjiffies) <
msecs_to_jiffies(40); )
+ for (oldjiffies = jiffies;
+time_before(jiffies, oldjiffies + msecs_to_jiffies(40)); )
if (qcam_ready1(qcam) == value)
return 0;
@@ -120,7 +122,8 @@ static unsigned int qcam_await_ready2(st
unsigned long oldjiffies = jiffies;
unsigned int i;
- for (oldjiffies = jiffies; (jiffies - oldjiffies) <
msecs_to_jiffies(40); )
+ for (oldjiffies = jiffies;
+time_before(jiffies, oldjiffies + msecs_to_jiffies(40)); )
if (qcam_ready2(qcam) == value)
return 0;
diff -r -u -p a/drivers/media/video/ivtv/ivtv-fileops.c
b/drivers/media/video/ivtv/ivtv-fileops.c
--- a/drivers/media/video/ivtv/ivtv-fileops.c 2007-11-01 10:30:39.0
+0100
+++ b/drivers/media/video/ivtv/ivtv-fileops.c 2007-12-23 20:37:15.0
+0100
@@ -219,7 +219,9 @@ static struct ivtv_buffer *ivtv_get_buff
/* Process pending program info updates and pending VBI
data */
ivtv_update_pgm_info(itv);
- if (jiffies - itv->dualwatch_jiffies >
msecs_to_jiffies(1000)) {
+ if (time_after(jiffies,
+ itv->dualwatch_jiffies +
+ msecs_to_jiffies(1000))) {
itv->dualwatch_jiffies = jiffies;
ivtv_dualwatch(itv);
}
diff -r -u -p a/drivers/media/video/ivtv/ivtv-mailbox.c
b/drivers/media/video/ivtv/ivtv-mailbox.c
--- a/drivers/media/video/ivtv/ivtv-mailbox.c 2007-10-22 11:25:10.0
+0200
+++ b/drivers/media/video/ivtv/ivtv-mailbox.c 2007-12-23 20:37:40.0
+0100
@@ -177,7 +177,8 @@ static int get_mailbox(struct ivtv *itv,
/* Sleep before a retry, if not atomic */
if (!(flags & API_NO_WAIT_MB)) {
- if (jiffies - then > msecs_to_jiffies(10*retries))
+ if (time_after(jiffies,
+ then + msecs_to_jiffies(10*retries)))
break;
ivtv_msleep_timeout(10, 0);
}
@@ -244,7 +245,9 @@ static int ivtv_api_call(struct ivtv *it
data, then just return 0 as there is no need to issue this command
again.
Just an optimization to prevent unnecessary use of mailboxes. */
if (itv->api_cache[cmd].last_jiffies &&
- jiffies - itv->api_cache[cmd].last_jiffies <
msecs_to_jiffies(180) &&
+ time_before(jiffies,
+ itv->api_cache[cmd].last_jiffies +
+ msecs_to_jiffies(180)) &&
!memcmp(data, itv->api_cache[cmd].data,
sizeof(itv->api_cache[cmd].data))) {
itv->api_cache[cmd].last_jiffies = jiffies;
return 0;
@@ -299,7 +302,7 @@ static int ivtv_api_call(struct ivtv *it
}
}
while (!(readl(>flags) & IVTV_MBOX_FIRMWARE_DONE)) {
- if (jiffies - then > api_timeout) {
+ if (time_after(jiffies, then + api_timeout)) {
IVTV_DEBUG_WARN("Could not get result (%s)\n",
api_info[cmd].name);
/* reset the mailbox, but it is likely too late already
*/
write_sync(0, >flags);
@@ -311,7 +314,7 @@ static int ivtv_api_call(struct ivtv *it
else
ivtv_msleep_timeout(1, 0);
}
- if (jiffies - then > msecs_to_jiffies(100))
+ if (time_after(jiffies, then + msecs_to_jiffies(100)))
IVTV_DEBUG_WARN("%s took %u jiffies\n",
api_info[cmd].name,
[PATCH 19/38] drivers/net/appletalk: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]> The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. A simplified version of the semantic patch making this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // @ change_compare_np @ expression E; @@ ( - jiffies <= E + time_before_eq(jiffies,E) | - jiffies >= E + time_after_eq(jiffies,E) | - jiffies < E + time_before(jiffies,E) | - jiffies > E + time_after(jiffies,E) ) @ include depends on change_compare_np @ @@ #include @ no_include depends on !include && change_compare_np @ @@ #include + #include // Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> --- diff -r -u -p a/drivers/net/appletalk/cops.c b/drivers/net/appletalk/cops.c --- a/drivers/net/appletalk/cops.c 2007-10-22 11:25:13.0 +0200 +++ b/drivers/net/appletalk/cops.c 2007-12-23 20:30:39.0 +0100 @@ -69,6 +69,7 @@ static const char *version = #include #include #include +#include #include #include @@ -503,7 +504,7 @@ static void cops_reset(struct net_device long snap=jiffies; /* Let card finish initializing, about 1/3 second */ - while(jiffies-snaphttp://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/38] drivers/media/dvb: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/media/dvb/frontends/stv0299.c
b/drivers/media/dvb/frontends/stv0299.c
--- a/drivers/media/dvb/frontends/stv0299.c 2007-10-22 11:25:10.0
+0200
+++ b/drivers/media/dvb/frontends/stv0299.c 2007-12-23 20:30:39.0
+0100
@@ -192,7 +192,7 @@ static int stv0299_wait_diseqc_fifo (str
dprintk ("%s\n", __FUNCTION__);
while (stv0299_readreg(state, 0x0a) & 1) {
- if (jiffies - start > timeout) {
+ if (time_after(jiffies, start + timeout)) {
dprintk ("%s: timeout!!\n", __FUNCTION__);
return -ETIMEDOUT;
}
@@ -209,7 +209,7 @@ static int stv0299_wait_diseqc_idle (str
dprintk ("%s\n", __FUNCTION__);
while ((stv0299_readreg(state, 0x0a) & 3) != 2 ) {
- if (jiffies - start > timeout) {
+ if (time_after(jiffies, start + timeout)) {
dprintk ("%s: timeout!!\n", __FUNCTION__);
return -ETIMEDOUT;
}
diff -r -u -p a/drivers/media/dvb/frontends/tda8083.c
b/drivers/media/dvb/frontends/tda8083.c
--- a/drivers/media/dvb/frontends/tda8083.c 2007-10-22 11:25:10.0
+0200
+++ b/drivers/media/dvb/frontends/tda8083.c 2007-12-23 20:30:39.0
+0100
@@ -171,7 +171,7 @@ static void tda8083_wait_diseqc_fifo (st
{
unsigned long start = jiffies;
- while (jiffies - start < timeout &&
+ while (time_before(jiffies, start + timeout) &&
!(tda8083_readreg(state, 0x02) & 0x80))
{
msleep(50);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git patches] IDE fixes
cmd64x regression bugfix, few obvious ide-cd fixes from the "redux" patch
peries and ide-cd MAINTAINERS entry update (Borislav, welcome on board!).
Oh yes, I would forget...
Merry Christmas!
Linus, please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
to receive the following updates:
MAINTAINERS |4 ++-
drivers/ide/ide-cd.c | 66 +++--
drivers/ide/ide-cd.h |3 +-
drivers/ide/pci/cmd64x.c |4 +-
drivers/ide/pci/cs5535.c |2 +-
5 files changed, 42 insertions(+), 37 deletions(-)
Bartlomiej Zolnierkiewicz (10):
ide-cd: fix SAMSUNG CD-ROM SCR-3231 quirk
ide-cd: fix ACER/AOpen 24X CDROM speed reporting on big-endian machines
ide-cd: use ide_cd_release() in ide_cd_probe()
ide-cd: fix error messages in cdrom_{read,write}_check_ireason()
ide-cd: add missing 'ireason' masking to cdrom_write_intr()
ide-cd: fix error messages in cdrom_write_intr()
ide-cd: add error message for DMA error to cdrom_read_intr()
ide-cd: fix error message in cdrom_pc_intr()
ide-cd: fix 'ireason' reporting in cdrom_pc_intr()
cmd64x: fix hwif->chipset setup
Borislav Petkov (1):
MAINTAINERS: update ide-cd entry
Joe Perches (1):
drivers/ide/: Spelling fixes
diff --git a/MAINTAINERS b/MAINTAINERS
index 3d567fd..79c711e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1870,8 +1870,10 @@ T: quilt
kernel.org/pub/linux/kernel/people/bart/pata-2.6/
S: Maintained
IDE/ATAPI CDROM DRIVER
+P: Borislav Petkov
+M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
-S: Unmaintained
+S: Maintained
IDE/ATAPI FLOPPY DRIVERS
P: Paul Bristow
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 92ac658..c7d77f0 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1068,8 +1068,8 @@ int cdrom_read_check_ireason (ide_drive_t *drive, int
len, int ireason)
return 0;
else if (ireason == 0) {
/* Whoops... The drive is expecting to receive data from us! */
- printk(KERN_ERR "%s: read_intr: Drive wants to transfer data
the "
- "wrong way!\n", drive->name);
+ printk(KERN_ERR "%s: %s: wrong transfer direction!\n",
+ drive->name, __FUNCTION__);
/* Throw some data at the drive so it doesn't hang
and quit this request. */
@@ -1086,8 +1086,8 @@ int cdrom_read_check_ireason (ide_drive_t *drive, int
len, int ireason)
return 0;
} else {
/* Drive wants a command packet, or invalid ireason... */
- printk(KERN_ERR "%s: read_intr: bad interrupt reason %x\n",
drive->name,
- ireason);
+ printk(KERN_ERR "%s: %s: bad interrupt reason 0x%02x\n",
+ drive->name, __FUNCTION__, ireason);
}
cdrom_end_request(drive, 0);
@@ -1112,8 +1112,11 @@ static ide_startstop_t cdrom_read_intr (ide_drive_t
*drive)
*/
if (dma) {
info->dma = 0;
- if ((dma_error = HWIF(drive)->ide_dma_end(drive)))
+ dma_error = HWIF(drive)->ide_dma_end(drive);
+ if (dma_error) {
+ printk(KERN_ERR "%s: DMA read error\n", drive->name);
ide_dma_off(drive);
+ }
}
if (cdrom_decode_status(drive, 0, ))
@@ -1443,7 +1446,7 @@ static ide_startstop_t cdrom_pc_intr (ide_drive_t *drive)
return ide_stopped;
/* Read the interrupt reason and the transfer length. */
- ireason = HWIF(drive)->INB(IDE_IREASON_REG);
+ ireason = HWIF(drive)->INB(IDE_IREASON_REG) & 0x3;
lowcyl = HWIF(drive)->INB(IDE_BCOUNTL_REG);
highcyl = HWIF(drive)->INB(IDE_BCOUNTH_REG);
@@ -1484,7 +1487,7 @@ static ide_startstop_t cdrom_pc_intr (ide_drive_t *drive)
if (thislen > len) thislen = len;
/* The drive wants to be written to. */
- if ((ireason & 3) == 0) {
+ if (ireason == 0) {
if (!rq->data) {
blk_dump_rq_flags(rq, "cdrom_pc_intr, write");
goto confused;
@@ -1506,9 +1509,9 @@ static ide_startstop_t cdrom_pc_intr (ide_drive_t *drive)
}
/* Same drill for reading. */
- else if ((ireason & 3) == 2) {
+ else if (ireason == 2) {
if (!rq->data) {
- blk_dump_rq_flags(rq, "cdrom_pc_intr, write");
+ blk_dump_rq_flags(rq, "cdrom_pc_intr, read");
goto confused;
}
/* Transfer the data. */
@@ -1632,8 +1635,8 @@ static int cdrom_write_check_ireason(ide_drive_t *drive,
int len, int ireason)
return 0;
else if (ireason ==
[PATCH 16/38] drivers/md: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/md/raid6algos.c b/drivers/md/raid6algos.c
--- a/drivers/md/raid6algos.c 2007-11-01 10:30:39.0 +0100
+++ b/drivers/md/raid6algos.c 2007-12-23 20:36:20.0 +0100
@@ -121,7 +121,8 @@ int __init raid6_select_algo(void)
j0 = jiffies;
while ( (j1 = jiffies) == j0 )
cpu_relax();
- while ( (jiffies-j1) < (1 << RAID6_TIME_JIFFIES_LG2) ) {
+ while ( time_before(jiffies,
+ j1 + (1
[PATCH 15/38] drivers/infiniband: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/infiniband/hw/ipath/ipath_intr.c
b/drivers/infiniband/hw/ipath/ipath_intr.c
--- a/drivers/infiniband/hw/ipath/ipath_intr.c 2007-11-01 10:30:39.0
+0100
+++ b/drivers/infiniband/hw/ipath/ipath_intr.c 2007-12-23 20:30:39.0
+0100
@@ -32,6 +32,7 @@
*/
#include
+#include
#include "ipath_kernel.h"
#include "ipath_verbs.h"
@@ -94,7 +95,7 @@ static void ipath_disarm_senderrbufs(str
if (sbuf[0] || sbuf[1] || (piobcnt > 128 && (sbuf[2] || sbuf[3]))) {
int i;
if (ipath_debug & (__IPATH_PKTDBG|__IPATH_DBG) &&
- dd->ipath_lastcancel > jiffies) {
+ time_before(jiffies, dd->ipath_lastcancel)) {
__IPATH_DBG_WHICH(__IPATH_PKTDBG|__IPATH_DBG,
"SendbufErrs %lx %lx", sbuf[0],
sbuf[1]);
@@ -635,7 +636,7 @@ static int handle_errors(struct ipath_de
/* likely due to cancel, so suppress */
if ((errs & (INFINIPATH_E_SPKTLEN | INFINIPATH_E_SPIOARMLAUNCH)) &&
- dd->ipath_lastcancel > jiffies) {
+ time_before(jiffies, dd->ipath_lastcancel)) {
ipath_dbg("Suppressed armlaunch/spktlen after error send
cancel\n");
errs &= ~(INFINIPATH_E_SPIOARMLAUNCH | INFINIPATH_E_SPKTLEN);
}
diff -r -u -p a/drivers/infiniband/hw/ipath/ipath_mad.c
b/drivers/infiniband/hw/ipath/ipath_mad.c
--- a/drivers/infiniband/hw/ipath/ipath_mad.c 2007-10-22 11:25:09.0
+0200
+++ b/drivers/infiniband/hw/ipath/ipath_mad.c 2007-12-23 20:35:37.0
+0100
@@ -1334,7 +1334,8 @@ static int process_subn(struct ib_device
}
/* Is the mkey in the process of expiring? */
- if (dev->mkey_lease_timeout && jiffies >= dev->mkey_lease_timeout) {
+ if (dev->mkey_lease_timeout &&
+ time_before_eq(jiffies, dev->mkey_lease_timeout)) {
/* Clear timeout and mkey protection field. */
dev->mkey_lease_timeout = 0;
dev->mkeyprot = 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/
[PATCH 13/38] drivers/char/keyboard.c: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/char/keyboard.c b/drivers/char/keyboard.c
--- a/drivers/char/keyboard.c 2007-10-22 11:25:05.0 +0200
+++ b/drivers/char/keyboard.c 2007-12-23 20:35:00.0 +0100
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
extern void ctrl_alt_del(void);
@@ -929,7 +930,8 @@ static void k_brl(struct vc_data *vc, un
if (up_flag) {
if (brl_timeout) {
if (!committing ||
- jiffies - releasestart > (brl_timeout * HZ) / 1000)
{
+ time_after(jiffies,
+ releasestart + (brl_timeout*HZ)/1000)) {
committing = pressed;
releasestart = jiffies;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 14/38] drivers/char/rtc.c: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]> The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. A simplified version of the semantic patch making this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // @ change_compare_np @ expression E; @@ ( - jiffies <= E + time_before_eq(jiffies,E) | - jiffies >= E + time_after_eq(jiffies,E) | - jiffies < E + time_before(jiffies,E) | - jiffies > E + time_after(jiffies,E) ) @ include depends on change_compare_np @ @@ #include @ no_include depends on !include && change_compare_np @ @@ #include + #include // Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> --- diff -r -u -p a/drivers/char/rtc.c b/drivers/char/rtc.c --- a/drivers/char/rtc.c2007-11-15 15:09:36.0 +0100 +++ b/drivers/char/rtc.c2007-12-23 20:35:15.0 +0100 @@ -88,6 +88,7 @@ #ifdef CONFIG_SPARC32 #include +#include #include static unsigned long rtc_port; @@ -1282,7 +1283,8 @@ void rtc_get_rtc_time(struct rtc_time *r * Once the read clears, read the RTC time (again via ioctl). Easy. */ - while (rtc_is_updating() != 0 && jiffies - uip_watchdog < 2*HZ/100) + while (rtc_is_updating() != 0 && + time_before(jiffies, uip_watchdog + 2*HZ/100)) cpu_relax(); /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 12/38] drivers/char/ds1286.c: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]> The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. A simplified version of the semantic patch making this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // @ change_compare_np @ expression E; @@ ( - jiffies <= E + time_before_eq(jiffies,E) | - jiffies >= E + time_after_eq(jiffies,E) | - jiffies < E + time_before(jiffies,E) | - jiffies > E + time_after(jiffies,E) ) @ include depends on change_compare_np @ @@ #include @ no_include depends on !include && change_compare_np @ @@ #include + #include // Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> --- diff -r -u -p a/drivers/char/ds1286.c b/drivers/char/ds1286.c --- a/drivers/char/ds1286.c 2007-06-02 22:32:10.0 +0200 +++ b/drivers/char/ds1286.c 2007-12-23 20:30:39.0 +0100 @@ -39,6 +39,7 @@ #include #include #include +#include #include #include @@ -451,7 +452,7 @@ static void ds1286_get_time(struct rtc_t */ if (ds1286_is_updating() != 0) - while (jiffies - uip_watchdog < 2*HZ/100) + while (time_before(jiffies, uip_watchdog + 2*HZ/100)) barrier(); /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 11/38] drivers/char/drm: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/char/drm/i830_irq.c b/drivers/char/drm/i830_irq.c
--- a/drivers/char/drm/i830_irq.c 2007-10-22 11:25:05.0 +0200
+++ b/drivers/char/drm/i830_irq.c 2007-12-23 20:30:39.0 +0100
@@ -90,7 +90,7 @@ static int i830_wait_irq(struct drm_devi
__set_current_state(TASK_INTERRUPTIBLE);
if (atomic_read(_priv->irq_received) >= irq_nr)
break;
- if ((signed)(end - jiffies) <= 0) {
+ if (time_before_eq(jiffies, end)) {
DRM_ERROR("timeout iir %x imr %x ier %x hwstam %x\n",
I830_READ16(I830REG_INT_IDENTITY_R),
I830_READ16(I830REG_INT_MASK_R),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 9/38] arch/x86/kernel/io_apic_{64,32}.c: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]> The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. A simplified version of the semantic patch making this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // @ change_compare_np @ expression E; @@ ( - jiffies <= E + time_before_eq(jiffies,E) | - jiffies >= E + time_after_eq(jiffies,E) | - jiffies < E + time_before(jiffies,E) | - jiffies > E + time_after(jiffies,E) ) @ include depends on change_compare_np @ @@ #include @ no_include depends on !include && change_compare_np @ @@ #include + #include // Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> --- diff -r -u -p a/arch/x86/kernel/io_apic_32.c b/arch/x86/kernel/io_apic_32.c --- a/arch/x86/kernel/io_apic_32.c 2007-12-21 06:57:18.0 +0100 +++ b/arch/x86/kernel/io_apic_32.c 2007-12-23 20:30:39.0 +0100 @@ -351,7 +351,8 @@ static void set_ioapic_affinity_irq(unsi # include /* kernel_thread() */ # include /* kstat */ # include/* kmalloc() */ -# include /* time_after() */ +# include +#include /* time_after() */ #define IRQBALANCE_CHECK_ARCH -999 #define MAX_BALANCED_IRQ_INTERVAL (5*HZ) @@ -1900,7 +1901,7 @@ static int __init timer_irq_works(void) * might have cached one ExtINT interrupt. Finally, at * least one tick may be lost due to delays. */ - if (jiffies - t1 > 4) + if (time_after(jiffies, t1 + 4)) return 1; return 0; diff -r -u -p a/arch/x86/kernel/io_apic_64.c b/arch/x86/kernel/io_apic_64.c --- a/arch/x86/kernel/io_apic_64.c 2007-12-21 06:57:18.0 +0100 +++ b/arch/x86/kernel/io_apic_64.c 2007-12-23 20:30:39.0 +0100 @@ -32,6 +32,7 @@ #include #include #include +#include #ifdef CONFIG_ACPI #include #endif @@ -1298,7 +1299,7 @@ static int __init timer_irq_works(void) */ /* jiffies wrap? */ - if (jiffies - t1 > 4) + if (time_after(jiffies, t1 + 4)) return 1; 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/
[PATCH 10/38] drivers/atm: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/drivers/atm/iphase.c b/drivers/atm/iphase.c
--- a/drivers/atm/iphase.c 2007-09-09 08:31:35.0 +0200
+++ b/drivers/atm/iphase.c 2007-12-23 20:34:34.0 +0100
@@ -60,7 +60,8 @@
#include
#include
#include
-#include
+#include
+#include
#include "iphase.h"
#include "suni.h"
#define swap(x) (((x & 0xff) << 8) | ((x & 0xff00) >> 8))
@@ -189,7 +190,7 @@ static u16 get_desc (IADEV *dev, struct
int ltimeout;
ia_hack_tcq (dev);
- if(((jiffies - timer)>50)||((dev->ffL.tcq_rd==dev->host_tcq_wr))){
+ if((time_after(jiffies,timer+50)) || ((dev->ffL.tcq_rd==dev->host_tcq_wr))) {
timer = jiffies;
i=0;
while (i < dev->num_tx_desc) {
@@ -1223,7 +1224,7 @@ static void rx_intr(struct atm_dev *dev)
iadev->rx_tmp_jif = jiffies;
iadev->rxing = 0;
}
- else if (((jiffies - iadev->rx_tmp_jif) > 50) &&
+ else if ((time_after(jiffies, iadev->rx_tmp_jif + 50)) &&
((iadev->rx_pkt_cnt - iadev->rx_tmp_cnt) == 0)) {
for (i = 1; i <= iadev->num_rx_desc; i++)
free_desc(dev, i);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/38] arch/x86/ia32: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
--- a/arch/x86/ia32/ia32_aout.c 2007-10-22 11:25:00.0 +0200
+++ b/arch/x86/ia32/ia32_aout.c 2007-12-23 20:31:29.0 +0100
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -344,14 +345,15 @@ static int load_aout_binary(struct linux
#ifdef WARN_OLD
static unsigned long error_time, error_time2;
if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
- (N_MAGIC(ex) != NMAGIC) && (jiffies-error_time2) > 5*HZ)
+ (N_MAGIC(ex) != NMAGIC) &&
+ time_after(jiffies, error_time2 + 5*HZ))
{
printk(KERN_NOTICE "executable not page aligned\n");
error_time2 = jiffies;
}
if ((fd_offset & ~PAGE_MASK) != 0 &&
- (jiffies-error_time) > 5*HZ)
+ time_after(jiffies, error_time + 5*HZ))
{
printk(KERN_WARNING
"fd_offset is not page aligned. Please convert
program: %s\n",
@@ -467,7 +469,7 @@ static int load_aout_library(struct file
#ifdef WARN_OLD
static unsigned long error_time;
- if ((jiffies-error_time) > 5*HZ)
+ if (time_after(jiffies, error_time + 5*HZ))
{
printk(KERN_WARNING
"N_TXTOFF is not page aligned. Please convert
library: %s\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 8/38] arch/x86/kernel/apm_32.c: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
--- a/arch/x86/kernel/apm_32.c 2007-10-22 11:25:00.0 +0200
+++ b/arch/x86/kernel/apm_32.c 2007-12-23 20:30:39.0 +0100
@@ -314,6 +314,7 @@ extern int (*console_blank_hook)(int);
#include
#include
#include
+#include
#endif
/*
@@ -1289,7 +1290,7 @@ static void check_events(void)
"event 0x%02x\n", event);
}
if (ignore_bounce
- && ((jiffies - last_resume) > bounce_interval))
+ && (time_after(jiffies, last_resume + bounce_interval)))
ignore_bounce = 0;
switch (event) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/38] arch/sparc64: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/arch/sparc64/kernel/binfmt_aout32.c
b/arch/sparc64/kernel/binfmt_aout32.c
--- a/arch/sparc64/kernel/binfmt_aout32.c 2007-10-22 11:24:59.0
+0200
+++ b/arch/sparc64/kernel/binfmt_aout32.c 2007-12-23 20:33:56.0
+0100
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -273,7 +274,8 @@ static int load_aout32_binary(struct lin
} else {
static unsigned long error_time;
if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
- (N_MAGIC(ex) != NMAGIC) && (jiffies-error_time) > 5*HZ)
+ (N_MAGIC(ex) != NMAGIC) &&
+ time_after(jiffies, error_time + 5*HZ))
{
printk(KERN_NOTICE "executable not page aligned\n");
error_time = jiffies;
diff -r -u -p a/arch/sparc64/kernel/unaligned.c
b/arch/sparc64/kernel/unaligned.c
--- a/arch/sparc64/kernel/unaligned.c 2007-06-02 22:32:07.0 +0200
+++ b/arch/sparc64/kernel/unaligned.c 2007-12-23 20:30:39.0 +0100
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
/* #define DEBUG_MNA */
@@ -283,7 +284,7 @@ static void log_unaligned(struct pt_regs
{
static unsigned long count, last_time;
- if (jiffies - last_time > 5 * HZ)
+ if (time_after(jiffies, last_time + 5 * HZ))
count = 0;
if (count < 5) {
last_time = jiffies;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/38] arch/powerpc: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/arch/powerpc/platforms/iseries/pci.c
b/arch/powerpc/platforms/iseries/pci.c
--- a/arch/powerpc/platforms/iseries/pci.c 2007-07-20 17:45:44.0
+0200
+++ b/arch/powerpc/platforms/iseries/pci.c 2007-12-23 20:30:39.0
+0100
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -405,7 +406,7 @@ static u8 iSeries_Read_Byte(const volati
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
@@ -434,7 +435,7 @@ static u16 iSeries_Read_Word(const volat
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
@@ -464,7 +465,7 @@ static u32 iSeries_Read_Long(const volat
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
@@ -498,7 +499,7 @@ static void iSeries_Write_Byte(u8 data,
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
@@ -524,7 +525,7 @@ static void iSeries_Write_Word(u16 data,
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
@@ -551,7 +552,7 @@ static void iSeries_Write_Long(u32 data,
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 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: Updated Kernel Hacker's guide to git
On Sun, 23 Dec 2007, Dieter Ries wrote: > Could you perhaps publish your reference list as kind of a christmas > gift to all basic users like me? FYI, i'm typing in my own reference list as we speak here: http://www.crashcourse.ca/wiki/index.php/Git still quite a bit to go, but you can get the overall idea. new sections should be appearing there as the morning progresses. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/38] arch/parisc: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/arch/parisc/kernel/unaligned.c b/arch/parisc/kernel/unaligned.c
--- a/arch/parisc/kernel/unaligned.c2007-10-22 11:24:58.0 +0200
+++ b/arch/parisc/kernel/unaligned.c2007-12-23 20:33:36.0 +0100
@@ -460,7 +460,8 @@ void handle_unaligned(struct pt_regs *re
goto force_sigbus;
}
- if (unaligned_count > 5 && jiffies - last_time > 5*HZ) {
+ if (unaligned_count > 5 &&
+ time_after(jiffies, last_time + 5*HZ)) {
unaligned_count = 0;
last_time = jiffies;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/38] arch/ia64: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/arch/ia64/kernel/irq_ia64.c b/arch/ia64/kernel/irq_ia64.c
--- a/arch/ia64/kernel/irq_ia64.c 2007-12-21 06:57:18.0 +0100
+++ b/arch/ia64/kernel/irq_ia64.c 2007-12-23 20:30:39.0 +0100
@@ -405,7 +405,7 @@ ia64_handle_irq (ia64_vector vector, str
static unsigned char count;
static long last_time;
- if (jiffies - last_time > 5*HZ)
+ if (time_after(jiffies, last_time + 5*HZ))
count = 0;
if (++count < 5) {
last_time = jiffies;
diff -r -u -p a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
--- a/arch/ia64/kernel/mca.c2007-12-21 06:57:18.0 +0100
+++ b/arch/ia64/kernel/mca.c2007-12-23 20:31:54.0 +0100
@@ -76,6 +76,7 @@
#include
#include
#include
+#include
#include
#include
@@ -285,7 +286,8 @@ static void ia64_mlogbuf_dump_from_init(
if (mlogbuf_finished)
return;
- if (mlogbuf_timestamp && (mlogbuf_timestamp + 30*HZ > jiffies)) {
+ if (mlogbuf_timestamp &&
+ (time_before(jiffies, mlogbuf_timestamp + 30*HZ))) {
printk(KERN_ERR "INIT: mlogbuf_dump is interrupted by INIT "
" and the system seems to be messed up.\n");
ia64_mlogbuf_finish(0);
diff -r -u -p a/arch/ia64/kernel/unaligned.c b/arch/ia64/kernel/unaligned.c
--- a/arch/ia64/kernel/unaligned.c 2007-10-22 11:24:57.0 +0200
+++ b/arch/ia64/kernel/unaligned.c 2007-12-23 20:30:39.0 +0100
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1289,7 +1290,7 @@ within_logging_rate_limit (void)
{
static unsigned long count, last_time;
- if (jiffies - last_time > 5*HZ)
+ if (time_after(jiffies, last_time + 5*HZ))
count = 0;
if (count < 5) {
last_time = jiffies;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/38] arch/ia64/sn: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/arch/ia64/sn/kernel/xpc_main.c b/arch/ia64/sn/kernel/xpc_main.c
--- a/arch/ia64/sn/kernel/xpc_main.c2007-11-12 10:35:56.0 +0100
+++ b/arch/ia64/sn/kernel/xpc_main.c2007-12-23 20:32:54.0 +0100
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -199,7 +200,7 @@ xpc_timeout_partition_disengage_request(
struct xpc_partition *part = (struct xpc_partition *) data;
- DBUG_ON(jiffies < part->disengage_request_timeout);
+ DBUG_ON(time_before(jiffies, part->disengage_request_timeout));
(void) xpc_partition_disengaged(part);
@@ -230,7 +231,7 @@ xpc_hb_beater(unsigned long dummy)
{
xpc_vars->heartbeat++;
- if (jiffies >= xpc_hb_check_timeout) {
+ if (time_before_eq(jiffies, xpc_hb_check_timeout)) {
wake_up_interruptible(_act_IRQ_wq);
}
@@ -270,7 +271,7 @@ xpc_hb_checker(void *ignore)
/* checking of remote heartbeats is skewed by IRQ handling */
- if (jiffies >= xpc_hb_check_timeout) {
+ if (time_before_eq(jiffies, xpc_hb_check_timeout)) {
dev_dbg(xpc_part, "checking remote heartbeats\n");
xpc_check_remote_hb();
@@ -305,7 +306,7 @@ xpc_hb_checker(void *ignore)
/* wait for IRQ or timeout */
(void) wait_event_interruptible(xpc_act_IRQ_wq,
(last_IRQ_count < atomic_read(_act_IRQ_rcvd) ||
- jiffies >= xpc_hb_check_timeout ||
+time_before_eq(jiffies, xpc_hb_check_timeout) ||
(volatile int) xpc_exiting));
}
diff -r -u -p a/arch/ia64/sn/kernel/xpc_partition.c
b/arch/ia64/sn/kernel/xpc_partition.c
--- a/arch/ia64/sn/kernel/xpc_partition.c 2007-06-02 22:32:05.0
+0200
+++ b/arch/ia64/sn/kernel/xpc_partition.c 2007-12-23 20:33:17.0
+0100
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -877,7 +878,8 @@ xpc_partition_disengaged(struct xpc_part
disengaged = (xpc_partition_engaged(1UL << partid) == 0);
if (part->disengage_request_timeout) {
if (!disengaged) {
- if (jiffies < part->disengage_request_timeout) {
+ if (time_before(jiffies,
+ part->disengage_request_timeout)) {
/* timelimit hasn't been reached yet */
return 0;
}
diff -r -u -p a/arch/mips/cobalt/reset.c b/arch/mips/cobalt/reset.c
--- a/arch/mips/cobalt/reset.c 2007-10-22 11:24:58.0 +0200
+++ b/arch/mips/cobalt/reset.c 2007-12-23 20:30:39.0 +0100
@@ -49,7 +49,7 @@ void cobalt_machine_halt(void)
if((diff & (COBALT_KEY_ENTER | COBALT_KEY_SELECT)) && !(~last &
(COBALT_KEY_ENTER | COBALT_KEY_SELECT)))
writeb(RESET, RESET_PORT);
- for (mark = jiffies; jiffies - mark < HZ;)
+ for (mark = jiffies; time_before(jiffies, mark + HZ);)
;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/38] arch/alpha: Use time_before, time_before_eq, etc.
From: Julia Lawall <[EMAIL PROTECTED]>
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@ change_compare_np @
expression E;
@@
(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)
@ include depends on change_compare_np @
@@
#include
@ no_include depends on !include && change_compare_np @
@@
#include
+ #include
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -r -u -p a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
--- a/arch/alpha/kernel/traps.c 2007-10-22 11:24:57.0 +0200
+++ b/arch/alpha/kernel/traps.c 2007-12-23 20:30:39.0 +0100
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -781,7 +782,7 @@ do_entUnaUser(void __user * va, unsigned
with the unaliged access. */
if (!test_thread_flag (TIF_UAC_NOPRINT)) {
- if (cnt >= 5 && jiffies - last_time > 5*HZ) {
+ if (cnt >= 5 && time_after(jiffies, last_time + 5*HZ)) {
cnt = 0;
}
if (++cnt < 5) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 4/4] usb: libusual: locking cleanup
On Sun, 23 Dec 2007 08:46:37 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote: > I noticed you also have a spinlock held in usu_probe_thread(), the > usu_lock.. That spinlock would preclude anything inside request_module() > from sleeping.. The usu_lock is not held across request_module. In fact, it can be easily taken from inside request_module, when it invokes modprobe. Stop scaring me :-) > One thing that has bothered me is that I don't see a reason why this > couldn't become a complete, yet you have a comment which says that it > can't be a complete.. I honestly didn't understand the comment.. I would > imagine that you tried a complete , and it didn't work? Yes, it was a completition initially. But suppose you have two storage devices, plugged in across a reboot. Two threads are created and have to wait until the libusual's init function ends. Since we post one completion, only one thread continues. -- Pete -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible fix for lockup in drop_caches
On Sat, 2007-12-22 at 02:06 -0800, Andrew Morton wrote:
> On Mon, 17 Dec 2007 12:13:22 + richard <[EMAIL PROTECTED]> wrote:
>
> > fix lockup in when calling drop_caches
> >
> > calling /proc/sys/vm/drop_caches can hang due to a AB/BA lock dependency
> > between j_list_lock and the inode_lock. This patch moves the redirtying
> > of the buffer head out
> > from under the j_list_lock.
> >
> > based on a suggestion by Andrew Morton.
> >
>
> Oh boy. Do we really want to add all this stuff to JBD just for
> drop_caches which is a silly root-only broken-in-22-other-ways thing?
It did end up with a lot of code but I was hoping that not taking 2
locks at the same time would have a positive performance benefit, not
just fix the lockup. But, so far I've not been able to find a benchmark
to show any consistent difference.
However, I'm getting some interesting numbers from iozone that suggest
this patch improves write performance when the buffers are small enough
to fit into memory, _but_ the results are very variable. I'm not sure
why the iozone results are so inconsistent, maybe oprofile will help.
Anyway more testing is needed :)
> Michael, might your convert-inode-lists-to-tree patches eliminate the need
> for taking inode_lock in drop_pagecache_sb()? Probably not, as it uses an
> rbtree. It would have been possible if it was using a radix-tree, I
> suspect..
>
> > -void __journal_unfile_buffer(struct journal_head *jh)
> > +void __journal_unfile_buffer(struct journal_head *jh,
> > + struct buffer_head **dirty_bh)
> > {
> > - __journal_temp_unlink_buffer(jh);
> > + __journal_temp_unlink_buffer(jh, dirty_bh);
> > jh->b_transaction = NULL;
> > }
>
> I suspect the code would end up simpler if __journal_unfile_buffer() were
> to take an additional ref on the bh which it placed at *dirty_bh.
>
> Callers of __journal_unfile_buffer() could then call
>
> void handle_dirty_bh(struct buffer_head *bh)
> {
> if (bh) {
> jbd_mark_buffer_dirty(bh);
> put_bh(bh);
> }
> }
thanks for the suggestion, that looks like a really clean approach, I'll
give it a try.
cheers
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] cmd64x: fix hwif->chipset setup
commit 528a572daea90aa41db92683e5a8756acef514c4 ("ide: add ->chipset field
to ide_pci_device_t") broke hwif->chipset setup (it is now set to ide_cmd646
for CMD648 instead of CMD646). It seems that the breakage happend while
I was moving patches around (cmd64x_chipsets[] entries for CMD646 and CMD648
are identical except for 'name' field). Fix it and bump driver version.
Cc: Sergei Shtylyov <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/cmd64x.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/ide/pci/cmd64x.c
===
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/cmd64x.c Version 1.51Nov 8, 2007
+ * linux/drivers/ide/pci/cmd64x.c Version 1.52Dec 24, 2007
*
* cmd64x.c: Enable interrupts at initialization time on Ultra/PCI machines.
* Due to massive hardware bugs, UltraDMA is only supported
@@ -564,6 +564,7 @@ static const struct ide_port_info cmd64x
.init_chipset = init_chipset_cmd64x,
.init_hwif = init_hwif_cmd64x,
.enablebits = {{0x51,0x04,0x04}, {0x51,0x08,0x08}},
+ .chipset= ide_cmd646,
.host_flags = IDE_HFLAG_ABUSE_PREFETCH | IDE_HFLAG_BOOTABLE,
.pio_mask = ATA_PIO5,
.mwdma_mask = ATA_MWDMA2,
@@ -573,7 +574,6 @@ static const struct ide_port_info cmd64x
.init_chipset = init_chipset_cmd64x,
.init_hwif = init_hwif_cmd64x,
.enablebits = {{0x51,0x04,0x04}, {0x51,0x08,0x08}},
- .chipset= ide_cmd646,
.host_flags = IDE_HFLAG_ABUSE_PREFETCH | IDE_HFLAG_BOOTABLE,
.pio_mask = ATA_PIO5,
.mwdma_mask = ATA_MWDMA2,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
New UML-Based Virtual Network
Hello, If you need a little network to test some of the kernel's networking functions, there is a simple virtual network available at http://clownix.net (uml_clownix_net). Vincent Perrier 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: 2.6.24-rc6-mm1: suspend broken on HP nx6325 due to cpufreq changes
On Monday, 24 of December 2007, Takashi Iwai wrote: > At Sun, 23 Dec 2007 14:50:03 -0800, > Andrew Morton wrote: > > > > > although it still is a > > > bit flaky (it takes well more than 5 seconds to suspend and the sound > > > adapter > > > doesn't work right after the resume, but it starts to work again about 10s > > > later). > > > > hm. There have been some suspend changes in the alsa tree. > > Not really. The usb-audio suspend support is the only addition on > mm. It should be irrelevant with on-board HD-audio... Well, I'm suspecting some ACPI changes, but will be only able to debug it further in a couple of days. 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: 2.6.24-rc6-mm1: suspend broken on HP nx6325 due to cpufreq changes
At Sun, 23 Dec 2007 14:50:03 -0800, Andrew Morton wrote: > > > although it still is a > > bit flaky (it takes well more than 5 seconds to suspend and the sound > > adapter > > doesn't work right after the resume, but it starts to work again about 10s > > later). > > hm. There have been some suspend changes in the alsa tree. Not really. The usb-audio suspend support is the only addition on mm. It should be irrelevant with on-board HD-audio... Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Monday, 24 of December 2007, Carlos Corbacho wrote: > On Monday 24 December 2007 01:14:34 Linus Torvalds wrote: > > Side note: we could obviously undo the commit that triggered this for you > > [..] > > In other words, we'd have to go back to our original ordering, which Len > > said was fundamentally wrong. I don't think anybody really wants that. > > Nor would I argue to do so. > > > It would be better to figure out why "device_suspend()" apparently causes > > problems for your AML crud. > > Will do - thanks for the pointer. Well, having considered that for a longer while, I think the AML code is referring to a device that we have suspended already, and since it's in a low power state, it just can't handle the reference. If that is the case, we'll have to find the device (that should be possible using some code instrumentation) and move the suspending of it into the late stage. > > Oh, and why is linux-kernel cc'd, but not linux-pm? > > Because I like to compound my errors (I mean, if you're going to screw up, > you > might as well _really_ go for it). BTW, linux-pm is on linux-foundation, changed the CC. ;-) Thanks, 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: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hello. Serge E. Hallyn wrote: > I apologize if I'm commiting a faux pas by asking this, but any chance > of renaming this to something like strictdev or sdev, or at least with > 'dev' in it somewhere? You are not commiting a faux pas. But, this naming is my personal feeling. ;-) You can see the origin at http://I-love.SAKURA.ne.jp/tomoyo/index-en.html . Happy Holidays! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Kernel Hacker's guide to git
On Sun, Dec 23, 2007 at 06:13:03AM -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: > Another year, another update! :) > > The kernel hacker's guide to git has received some updates: > > http://linux.yyz.us/git-howto.html one minor note: i would suggest using: $ git shortlog master..HEAD instead of $ git log master..HEAD | git shortlog to avoid unnecessary complexity :) thanks, - VMiklos pgp6j1Oh11j8r.pgp Description: PGP signature
Re: Correct use of __init and __devinit
On Sun, Dec 23, 2007 at 04:56:14PM +, Adrian McMenamin wrote: > Could someone here help settle this argument? > > I have written a driver (for the CD Rom on the Sega Dreamcast). I have > marked various initialisation functions - including probe() and the > functions that it, and only it, calls, as __init. > > Other developers tell me I should mark them as __devinit. > > However I think this is wrong as: > > * The CD on the Dreamcast is not and will never be a hotpluggable device > > * The Dreamcast is a limited memory device and if marking various > functions as __init helps save memory that is A Good Thing > > It has been put to me that while the use case (not hotpluggable) is > correct, it is still better practice to use __devinit If you use the register* functions of the driver model then you are no longer in 100% control when your functions are called. So of the principle of least suprise it is best to use __devinit for the probe function as most other drivers do. And if the driver model happens to call your probe function after init time then we will not oops. So wit other words - use same pattern a other drivers and accept that we could have saved a few hundred bytes extra but we do not do so. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCHES] V4L/DVB updates
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git master For two trivial driver fixes: - A fix at Kconfig to DVB_LGDT330X be selected on cx23885; - Some ivtv boards requres a longer i2c udelay for they to work. Cheers, Mauro. --- drivers/media/video/cx23885/Kconfig |1 + drivers/media/video/ivtv/ivtv-i2c.c |3 +++ 2 files changed, 4 insertions(+), 0 deletions(-) Hans Verkuil (1): V4L/DVB (6876): ivtv: mspx4xx needs a longer i2c udelay Michael Krufky (1): V4L/DVB (6871): Kconfig: VIDEO_CX23885 must select DVB_LGDT330X --- V4L/DVB development is hosted at http://linuxtv.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Circular locking dependency
Hi,
Just hit this on sched-devel. (not sure how to reproduce it yet, can't
try now. I believe i can hit it on mainline as well as there is nothing
scheduler specific).
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc6 #1
---
bash/17982 is trying to acquire lock:
(>j_list_lock){--..}, at: []
__journal_try_to_free_buffer+0x2a/0x8a
but task is already holding lock:
(inode_lock){--..}, at: [] drop_pagecache_sb+0x12/0x74
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (inode_lock){--..}:
[] check_prev_add+0xb8/0x1ad
[] check_prevs_add+0x5d/0xcf
[] validate_chain+0x286/0x300
[] __lock_acquire+0x67f/0x6ff
[] lock_acquire+0x71/0x8b
[] _spin_lock+0x2b/0x38
[] __mark_inode_dirty+0xd0/0x15b
[] __set_page_dirty+0x10c/0x11b
[] mark_buffer_dirty+0x9a/0xa1
[] __journal_temp_unlink_buffer+0xbf/0xc3
[] __journal_unfile_buffer+0xb/0x15
[] __journal_refile_buffer+0x3c/0x86
[] journal_commit_transaction+0x89c/0xa05
[] kjournald+0xab/0x1ff
[] kthread+0x37/0x59
[] kernel_thread_helper+0x7/0x10
[] 0x
-> #0 (>j_list_lock){--..}:
[] check_prev_add+0x2e/0x1ad
[] check_prevs_add+0x5d/0xcf
[] validate_chain+0x286/0x300
[] __lock_acquire+0x67f/0x6ff
[] lock_acquire+0x71/0x8b
[] _spin_lock+0x2b/0x38
[] __journal_try_to_free_buffer+0x2a/0x8a
[] journal_try_to_free_buffers+0x61/0x9e
[] ext3_releasepage+0x68/0x74
[] try_to_release_page+0x33/0x47
[] invalidate_complete_page+0x1e/0x35
[] __invalidate_mapping_pages+0x6b/0xc2
[] drop_pagecache_sb+0x4c/0x74
[] drop_pagecache+0x4a/0x78
[] drop_caches_sysctl_handler+0x36/0x4e
[] proc_sys_write+0x6b/0x85
[] vfs_write+0x8c/0x10b
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5f/0xa5
[] 0x
other info that might help us debug this:
2 locks held by bash/17982:
#0: (>s_umount_key#15){}, at: []
drop_pagecache+0x3d/0x78
#1: (inode_lock){--..}, at: [] drop_pagecache_sb+0x12/0x74
stack backtrace:
Pid: 17982, comm: bash Not tainted 2.6.24-rc6 #1
[] show_trace_log_lvl+0x19/0x2e
[] show_trace+0x12/0x14
[] dump_stack+0x6c/0x72
[] print_circular_bug_tail+0x5f/0x68
[] check_prev_add+0x2e/0x1ad
[] check_prevs_add+0x5d/0xcf
[] validate_chain+0x286/0x300
[] __lock_acquire+0x67f/0x6ff
[] lock_acquire+0x71/0x8b
[] _spin_lock+0x2b/0x38
[] __journal_try_to_free_buffer+0x2a/0x8a
[] journal_try_to_free_buffers+0x61/0x9e
[] ext3_releasepage+0x68/0x74
[] try_to_release_page+0x33/0x47
[] invalidate_complete_page+0x1e/0x35
[] __invalidate_mapping_pages+0x6b/0xc2
[] drop_pagecache_sb+0x4c/0x74
[] drop_pagecache+0x4a/0x78
[] drop_caches_sysctl_handler+0x36/0x4e
[] proc_sys_write+0x6b/0x85
[] vfs_write+0x8c/0x10b
[] sys_write+0x3d/0x61
[] sysenter_past_esp+0x5f/0xa5
===
[EMAIL PROTECTED] kernel]#
Last thing I did was echo 1 > /proc/sys/vm/drop_cache
(Not sure whom to cc, hopefully others will know better, also no time to
debug further, sorry!)
--
regards,
Dhaval
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Mon, 24 Dec 2007 06:54:30 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Arjan van de Ven wrote: > > I can see the point of having a sysfs attribute to enable MMCONF > > from userspace, so that userland diagnostics tools can turn it on > > if they really really want to. (I'd make that printk a nice warning > > "application XYZ is enabling extended config space for devize ABC" > > so that if the box then crashes and burns, people know who/why and > > where to direct their emails ;-) > > > > We did something similar for "enable", it's maybe 10 lines of code > > or so. > > > > I would assume lspci and friends would then only turn that on at > > explicit admin request > > Absolutely... I'm not asking to default it on, just asking for it to > be possible :) > ok so to summarize things a bit (I'll admit bias here but still ;) 1) having a per driver function to say "I'd like extended config space" is ok (it's the driver that knows what is needed after all) 2) we need a way for userspace to do the same for a given device (which then will print a nice warning who does what to whom) 3) we need to have the "no extended config space unless someone wants it" behavior 4) It's inevitable that this will end up being per device given that we'll end up with per device "this one is b0rked" quirks over time (even shortly) 5) architectures that have sane extended config space access should just be able to provide it always. This could even be on x86 based on BIOS date (say 2009 :) the patch I posted does 1) 3) 4) and the first half of 5) I'll update the patch to do 2) and the rest of 5) Is there anything I skipped in the summary above? (and yes I realize this needs lspci to be expanded some to set the flag if the admin really asks for it, but such is life) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Arjan van de Ven wrote: I can see the point of having a sysfs attribute to enable MMCONF from userspace, so that userland diagnostics tools can turn it on if they really really want to. (I'd make that printk a nice warning "application XYZ is enabling extended config space for devize ABC" so that if the box then crashes and burns, people know who/why and where to direct their emails ;-) We did something similar for "enable", it's maybe 10 lines of code or so. I would assume lspci and friends would then only turn that on at explicit admin request Absolutely... I'm not asking to default it on, just asking for it to be possible :) Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Mon, 24 Dec 2007 02:04:41 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> >> 3) mmconfig might or might not be enabled, depending on which
> >> driver is loaded, whether it called an API or not.
> >>
> >>Even LESS testing by hw vendors than #2. Maybe even
> >> "never"
> >>
> >>Inconsistent (config access depends on device)
> >
> > the "depends on device" is even true for Linux today. For us today,
> > MMCONFIG isn't always used, it's used on a per device basis
> > already; except that the per-device is both defined by the bios and
> > our quirks (the mmconfig code already falls back to conf1
> > cycles in various cases)
> >
> > So I'm not entirely buying your argument. IN fact I'm not buying
> > your "mixed is not tested at all" argument; while the statement may
> > be true, it's not different than it is from Linux today... which is
> > mixed. Just differently mixed I suppose.
>
> /If/ mixed use is truly well tested, then that eliminates one of my
> two objections.
>
> But I don't see that in the code now... I see we choose [get_virt()
> in mmconfig_{32,6 4}.c} strictly on a per-bus basis, based on the
> allowed bus list provided by the BIOS.
and this is PCI express only; afaik (but I could be wrong) it's pretty much a
bus per device there in a 1:1 way
> And -- please forgive me, I mean no offense here -- we have to make
> sure whatever rule we come up with makes AMD and other non-Intel
> folks happy. Like with PCI MSI, mmconfig (+ its Linux support) has a
> history of being written first for Intel, working great on select
> Intel platforms, and not working so great initially for other vendors
> even when said technology is supposedly compatible. So having AMD
> sign-off on such an approach would greatly increase comfort level.
they're very welcome to chime in.
At this point the majority of the mmconfig nightmares are for non-Intel (not
that Intel
gets it right, but the current diagnostics work there pretty ok), so these
patches are
aimed for non-Intel boxes in the first place.
> The second objection was regarding the inconsistencies introduced to
> userland (and the kernel?) whereby the existing states:
>
> * 256b config space
> * on per-bus basis, ext cfg space is available
> if device provides && mmconfig active
>
> were joined by the additional state
>
> * on a per-bus basis, ext cfg space is available
> if device provides && mmconfig active
>
> which has the potential to confuse the codebase that makes
> assumptions based upon whole system (mmconfig or not) and per-bus
> (ext cfg space capable or not) basis.
right now they very very very rarely see the extended space in the first place.
(since on a LOT of the machines it just is turned off due to our very very
strict
checks, which are MUCH more strict than the standards allow for). In addition,
it's not even unlikely
that there will be per-device quirks where we have to disable mmconfig for a
specific device
(see recent mails about that), at which point this is game over anyway; unless
you want that kind of
thing to just disable mmconfig for the entire bus, which would be WAY overkill.
I can see the point of having a sysfs attribute to enable MMCONF from
userspace, so
that userland diagnostics tools can turn it on if they really really want to.
(I'd make that printk a nice warning "application XYZ is enabling extended
config space for devize ABC" so
that if the box then crashes and burns, people know who/why and where to direct
their emails ;-)
We did something similar for "enable", it's maybe 10 lines of code or so.
I would assume lspci and friends would then only turn that on at explicit admin
request
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability
"Peer Chen" <[EMAIL PROTECTED]> writes: > I feel it's dangerous to set the En bit on Intel platform, If the HT MSI > En is set, the MSI should be expected to transform to HT INT message > format. It may cause interrupt lost or hardware internal state machine > failed depend on the hardware design. Reasonable. As long as what the quirk is to avoid errata and chipset specific issues I don't have a problem with it. I figure the quirk should be a separate patch though. My concern is that the general rule that always enabling HT MSI mapping capabilities is reasonable. Even if there are some specific exceptions where we don't want to do that. I want code that requires the smallest list of chipset exceptions that we can make. 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: [PATCH] include/asm-m68knommu/: Spelling fixes
Joe Perches wrote: Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Acked-by: Greg Ungerer <[EMAIL PROTECTED]> --- include/asm-m68knommu/bitops.h |2 +- include/asm-m68knommu/commproc.h|2 +- include/asm-m68knommu/delay.h |2 +- include/asm-m68knommu/m5249sim.h|4 ++-- include/asm-m68knommu/m5307sim.h| 12 ++-- include/asm-m68knommu/m5407sim.h| 12 ++-- include/asm-m68knommu/m68360_regs.h |2 +- include/asm-m68knommu/mcfuart.h |2 +- 8 files changed, 19 insertions(+), 19 deletions(-) diff --git a/include/asm-m68knommu/bitops.h b/include/asm-m68knommu/bitops.h index f8dfb7b..89b928f 100644 --- a/include/asm-m68knommu/bitops.h +++ b/include/asm-m68knommu/bitops.h @@ -262,7 +262,7 @@ static __inline__ unsigned long ext2_find_next_zero_bit(void *addr, unsigned lon * tmp = __swab32(*(p++)); * tmp |= ~0UL >> (32-offset); * -* but this would decrease preformance, so we change the +* but this would decrease performance, so we change the * shift: */ tmp = *(p++); diff --git a/include/asm-m68knommu/commproc.h b/include/asm-m68knommu/commproc.h index 0161ebb..36e870b 100644 --- a/include/asm-m68knommu/commproc.h +++ b/include/asm-m68knommu/commproc.h @@ -715,7 +715,7 @@ extern void cpm_install_handler(int vec, void (*handler)(void *), void *dev_id); #defineCICR_SCC_SCC3 ((uint)0x0020) /* SCC3 @ SCCc */ #defineCICR_SCB_SCC2 ((uint)0x0004) /* SCC2 @ SCCb */ #defineCICR_SCA_SCC1 ((uint)0x) /* SCC1 @ SCCa */ -#define CICR_IRL_MASK ((uint)0xe000) /* Core interrrupt */ +#define CICR_IRL_MASK ((uint)0xe000) /* Core interrupt */ #define CICR_HP_MASK ((uint)0x1f00) /* Hi-pri int. */ #define CICR_IEN ((uint)0x0080) /* Int. enable */ #define CICR_SPS ((uint)0x0001) /* SCC Spread */ diff --git a/include/asm-m68knommu/delay.h b/include/asm-m68knommu/delay.h index 04a20fd..55cbd62 100644 --- a/include/asm-m68knommu/delay.h +++ b/include/asm-m68knommu/delay.h @@ -68,7 +68,7 @@ static inline void _udelay(unsigned long usecs) /* * Moved the udelay() function into library code, no longer inlined. * I had to change the algorithm because we are overflowing now on - * the faster ColdFire parts. The code is a little biger, so it makes + * the faster ColdFire parts. The code is a little bigger, so it makes * sense to library it. */ extern void udelay(unsigned long usecs); diff --git a/include/asm-m68knommu/m5249sim.h b/include/asm-m68knommu/m5249sim.h index 399814f..366eb86 100644 --- a/include/asm-m68knommu/m5249sim.h +++ b/include/asm-m68knommu/m5249sim.h @@ -43,10 +43,10 @@ #define MCFSIM_CSAR1 0x8c/* CS 1 Address reg (r/w) */ #define MCFSIM_CSMR1 0x90/* CS 1 Mask reg (r/w) */ #define MCFSIM_CSCR1 0x96/* CS 1 Control reg (r/w) */ -#define MCFSIM_CSAR2 0x98/* CS 2 Adress reg (r/w) */ +#define MCFSIM_CSAR2 0x98/* CS 2 Address reg (r/w) */ #define MCFSIM_CSMR2 0x9c/* CS 2 Mask reg (r/w) */ #define MCFSIM_CSCR2 0xa2/* CS 2 Control reg (r/w) */ -#define MCFSIM_CSAR3 0xa4/* CS 3 Adress reg (r/w) */ +#define MCFSIM_CSAR3 0xa4/* CS 3 Address reg (r/w) */ #define MCFSIM_CSMR3 0xa8/* CS 3 Mask reg (r/w) */ #define MCFSIM_CSCR3 0xae/* CS 3 Control reg (r/w) */ diff --git a/include/asm-m68knommu/m5307sim.h b/include/asm-m68knommu/m5307sim.h index d3ce550..5886728 100644 --- a/include/asm-m68knommu/m5307sim.h +++ b/include/asm-m68knommu/m5307sim.h @@ -64,22 +64,22 @@ #define MCFSIM_CSMR7 0xda/* CS 7 Mask reg (r/w) */ #define MCFSIM_CSCR7 0xde/* CS 7 Control reg (r/w) */ #else -#define MCFSIM_CSAR2 0x98/* CS 2 Adress reg (r/w) */ +#define MCFSIM_CSAR2 0x98/* CS 2 Address reg (r/w) */ #define MCFSIM_CSMR2 0x9c/* CS 2 Mask reg (r/w) */ #define MCFSIM_CSCR2 0xa2/* CS 2 Control reg (r/w) */ -#define MCFSIM_CSAR3 0xa4/* CS 3 Adress reg (r/w) */ +#define MCFSIM_CSAR3 0xa4/* CS 3 Address reg (r/w) */ #define MCFSIM_CSMR3 0xa8/* CS 3 Mask reg (r/w) */ #define MCFSIM_CSCR3 0xae/* CS 3 Control reg (r/w) */ -#define MCFSIM_CSAR4 0xb0/* CS 4 Adress reg (r/w) */ +#define MCFSIM_CSAR4 0xb0/* CS 4 Address reg (r/w) */ #define MCFSIM_CSMR4 0xb4/* CS 4 Mask reg (r/w) */ #define MCFSIM_CSCR4
Re: [PATCH - SH/Dreamcast] CD-Rom (GD-Rom) support for the SEGA Dreamcast
On Sunday 23 December 2007, Adrian McMenamin wrote: > On 23/12/2007, Adrian McMenamin <[EMAIL PROTECTED]> wrote: > > This patch adds support for the CD-Rom (the so-called "GD-Rom") on the > > SEGA Dreamcast. > > > > The GD-Rom is based on the ATA-3 standard but implements a proprietary > > packet interface - the so-called Sega Packet Interface (SPI) and > > supports a proprietary CD format (the "Giga Disk"). This driver > > implements the SPI at least partially and will also read GD disks. > > > > There was a CD Rom driver for the 2.4 kernel series (out of mainline). > > This, though, is new code and unlike the previous driver uses DMA and > > not PIO to read disks. > > > > This is the third iteration of this patch - there remains the issue of > > __init versus __devinit - see http://lkml.org/lkml/2007/12/23/130 but > > I think otherwise it has dealt with most people's suggestions. The one > > exception is that Jens suggested using sector_div, though I found that > > did not work. > > Unfortunately that patch was lined wrapped. what e-mail client do you use ? they usually have options for you to turn off line wrapping ... > Here it is (actually, slightly fixed) again. running it through checkpatch finds a few syntax issues ... might want to do that real quick and post a new one (just ignore the 80 chars warning as you see fit). -mike signature.asc Description: This is a digitally signed message part.
