Is netif_tx_lock() SMP PREEMPT safe?
Hi all,
As in: include/linux/netdevice.h (kernel-2.6.24.2) one finds:
static inline void __netif_tx_lock(struct net_device *dev, int cpu)
{
spin_lock(&dev->_xmit_lock);
dev->xmit_lock_owner = cpu;
}
static inline void netif_tx_lock(struct net_device *dev)
{
__netif_tx_lock(dev, smp_processor_id());
}
Does netif_tx_lock(struct net_device *dev) expands into:
cpu = smp_processor_id();
spin_lock(&dev->_xmit_lock);
dev->xmit_lock_owner = cpu; /* cpu is not the lock owner */
Or to:
spin_lock(&dev->_xmit_lock);
dev->xmit_lock_owner = smp_processor_id();
which is correct?
Thanks in advance for your answer.
Regards
Marin Mitov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
net: tx timeouts with skge, 8139too, dmfe drivers/NICs
Hi all, I experience very rare freezes at heavy outbound traffic (sending ~4GB DVD image to another host(s) on the same LAN) using skge driver (NIC on the mobo) as well as (recently tested) using rtl8139 or dmfe NICs on the PCI bus. There is a single switch between them (tested with another one just to exclude a faulty switch). skge <--> Marvell 88E8001 chip 8139too <--> Realtek 8136B chip dmfe <--> Davicom DM9102 chip Symptoms are similar: tx timeouts and no more net activity. KDE desktop works, computational programs - work, the machine is usable, but cannot ping, nor can be ping-ed anymore. rmmod && modprobe the respective modules repairs the problem. Simple surfing/e-mailing from it do not trigger the problem. The machine is used as LTSP server for old PCs (as X terminals) (mostly outbound traffic) and is not usable as such due to this problem. The kernel is 2.6.24.2-SMP/x86_32 (PREEMPT or not - NO difference). As far as this happens with 3 different NICs/drivers could it be a problem in the (common for all of them) networking subsystem? As far as many persons are working on this machine only limited testing could be done. Thank you in advance for your suggestions, help (and patches). Regards. Marin Mitov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net: tx timeouts with skge, 8139too, dmfe drivers/NICs
On Monday 25 February 2008 10:53:01 pm you wrote: > Marin Mitov wrote: > > Hi all, > > > > I experience very rare freezes at heavy outbound traffic > > (sending ~4GB DVD image to another host(s) on the same LAN) > > using skge driver (NIC on the mobo) as well as (recently tested) > > using rtl8139 or dmfe NICs on the PCI bus. There is a single > > switch between them (tested with another one just to exclude > > a faulty switch). > > > > skge <--> Marvell 88E8001 chip > > 8139too <--> Realtek 8136B chip > > dmfe <--> Davicom DM9102 chip > > > > Symptoms are similar: tx timeouts and no more net activity. > > KDE desktop works, computational programs - work, the machine > > is usable, but cannot ping, nor can be ping-ed anymore. > > rmmod && modprobe the respective modules repairs the problem. > > Simple surfing/e-mailing from it do not trigger the problem. > > > > The machine is used as LTSP server for old PCs (as X terminals) > > (mostly outbound traffic) and is not usable as such due to this > > problem. > > > > The kernel is 2.6.24.2-SMP/x86_32 (PREEMPT or not - NO difference). > > > > As far as this happens with 3 different NICs/drivers could it be > > a problem in the (common for all of them) networking subsystem? > > A TX timeout (like hardware timeouts, in general) is a very generic > behavior, with many causes. > > In general, when you see timeouts with varied hardware and drivers, > you're almost always dealing with a problem with interrupt delivery, or All the drivers are using #INTA on PCI bus (no MSI/MSI-X). "problem with interrupt delivery" - you suspect interrupts incorrectly disabled (lost) in the drivers or faulty hardware(motherboard)? > a generic system problem, rather than bugs in the network stack or all "a generic system problem" - bad config or faulty hardware(motherboard)? Where I should look for the problem? Just for info: the system is very stable - uptime (if no power outages) could be a month or more (rebooting for kernel changes or updates). Marin Mitov > three drivers. > > Jeff > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net: tx timeouts with skge, 8139too, dmfe drivers/NICs
Hi Stephen, > Make sure the interrupt is showing up as level triggered in > /proc/interrupts. The BIOS may be configuring it as edge-triggered and that > won't work with Ethernet drivers that use NAPI. for: skge <--> Marvell 88E8001 chip cat /proc/interrupts gives (AMD64 X2 SMP): CPU0 CPU1 21: 11691000 11933174 IO-APIC-fasteoi eth0 It is neither IO-APIC-edge, nor IO-APIC-level. Could it be the problem? Marin Mitov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] net driver updates
On Tuesday 26 February 2008 12:59:04 am you wrote: > Divy Le Ray wrote: > >> From: "Divy Le Ray" <[EMAIL PROTECTED]> > >> Date: Wed, 20 Feb 2008 21:57:08 -0800 > >> > >>> The driver is cxgb3 here, it uses LLTX. > >> > >> That's extremely unfortunate, hopefully you can update it to > >> use a model like tg3 and others use. LLTX is a lost cause > >> for hardware device drivers, and in fact we'd like to remove > >> it tree wide eventually. Just for info: loopback.c uses it too :-) > > > > It sounds like I messed up. > > cxgb3 does not use LLTX - The Chelsio driver does, thus should be > > converted. > > So, it sounds like Krishna's patch is ok, because the race does not > exist anymore in this driver? > > Jeff > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]new_TSC_based_delay_tsc()
Hi all,
Please ignore the previous patch with the same subject.
It has a bug that can manifest itself in the very exotic case
when each do {} while() iteration executes on different cpu
leading to potentially infinite loop.
This is a patch based on the Ingo's idea/patch to track
delay_tsc() migration to another cpu by comparing
smp_processor_id(). It is against kernel-2.6.24-rc3.
What is different:
1. Using unsigned (instead of long) to unify for i386/x86_64.
2. Minimal preempt_disable/enable() critical sections
(more room for preemption)
3. some statements have been rearranged, to account for
possible under/overflow of left/TSC
Tested on both: 32/64 bit SMP PREEMPT kernel-2.6.24-rc3
Comments, please.
Signed-off-by: Marin Mitov <[EMAIL PROTECTED]>
=
--- a/arch/x86/lib/delay_32.c 2007-11-18 08:14:05.0 +0200
+++ b/arch/x86/lib/delay_32.c 2007-11-20 19:03:52.0 +0200
@@ -38,18 +38,42 @@
:"0" (loops));
}
-/* TSC based delay: */
+/* TSC based delay:
+ *
+ * We are careful about preemption as TSC's are per-CPU.
+ */
static void delay_tsc(unsigned long loops)
{
- unsigned long bclock, now;
+ unsigned prev, prev_1, now;
+ unsigned left = loops;
+ unsigned prev_cpu, cpu;
+
+ preempt_disable();
+ rdtscl(prev);
+ prev_cpu = smp_processor_id();
+ preempt_enable();
+ now = prev;
- preempt_disable(); /* TSC's are per-cpu */
- rdtscl(bclock);
do {
rep_nop();
+
+ left -= now - prev;
+ prev = now;
+
+ preempt_disable();
+ rdtscl(prev_1);
+ cpu = smp_processor_id();
rdtscl(now);
- } while ((now-bclock) < loops);
- preempt_enable();
+ preempt_enable();
+
+ if (prev_cpu != cpu){
+ /*
+* We have migrated, forget prev_cpu's tsc reading
+*/
+ prev = prev_1;
+ prev_cpu = cpu;
+ }
+ } while ((now-prev) < left);
}
/*
--- a/arch/x86/lib/delay_64.c 2007-11-18 08:14:40.0 +0200
+++ b/arch/x86/lib/delay_64.c 2007-11-20 19:47:29.0 +0200
@@ -26,18 +26,42 @@
return 0;
}
+/* TSC based delay:
+ *
+ * We are careful about preemption as TSC's are per-CPU.
+ */
void __delay(unsigned long loops)
{
- unsigned bclock, now;
+ unsigned prev, prev_1, now;
+ unsigned left = loops;
+ unsigned prev_cpu, cpu;
+
+ preempt_disable();
+ rdtscl(prev);
+ prev_cpu = smp_processor_id();
+ preempt_enable();
+ now = prev;
- preempt_disable(); /* TSC's are pre-cpu */
- rdtscl(bclock);
do {
- rep_nop();
+ rep_nop();
+
+ left -= now - prev;
+ prev = now;
+
+ preempt_disable();
+ rdtscl(prev_1);
+ cpu = smp_processor_id();
rdtscl(now);
- }
- while ((now-bclock) < loops);
- preempt_enable();
+ preempt_enable();
+
+ if (prev_cpu != cpu){
+ /*
+* We have migrated, forget prev_cpu's tsc reading
+*/
+prev = prev_1;
+prev_cpu = cpu;
+ }
+ } while ((now-prev) < left);
}
EXPORT_SYMBOL(__delay);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: some thoughts about TSC based delay_tsc()
On Wednesday 21 November 2007 09:27:54 pm you wrote: > * Marin Mitov <[EMAIL PROTECTED]> wrote: > > Hi Ingo, > > > > The patch is quite good ;-) but we forget when it is needed :-( In > > fact we need it only for PREEMPT SMP kernels - it could hurt PREEMPT > > UP kernels (no migration possible), so no need for > > preempt_disable()/preempt_enable(). > > > > In short the old version of delay_tsc() is good for UP kernels and NON > > PREEMPT SMP kernels too. > > please reply to the public list, so that discussions do not get lost. > > i dont think there's any problem: udelay() is about _wasting_ cycles - > it's what drivers use for short delays. Sure for the thread executing udelay(), but not for the other ready threads which should also wait till preempt_enable() to grab the same cpu even for PREEMPT (UP or SMP) kernels (or I misunderstand something?). Marin > > Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.24-rc3-mm1: usb mouse doesn't work
On Thursday 22 November 2007 07:07:00 pm you wrote: > On Thu, 22 Nov 2007, Kirill A. Shutemov wrote: > > > > uhci_hcd :00:1d.3: UHCI Host Controller > > > > uhci_hcd :00:1d.3: new USB bus registered, assigned bus number 4 > > > > uhci_hcd :00:1d.3: irq 7, io base 0xbf20 > > > > usb usb4: configuration #1 chosen from 1 choice > > > > hub 4-0:1.0: USB hub found > > > > hub 4-0:1.0: 2 ports detected > > > > usb usb4: new device found, idVendor=, idProduct= > > > > usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1 > > > > usb usb4: Product: UHCI Host Controller > > > > usb usb4: Manufacturer: Linux 2.6.24-kas-alt1 uhci_hcd > > > > usb usb4: SerialNumber: :00:1d.3 > > > > uhci_hcd :00:1d.3: FGR not stopped yet! > > > > > > I've had some strangenesses with USB lately. Sometimes running `lsusb' > > > makes the USB system notice a newly attached device. > > > > No. But I have new messages in dmesg: > > > > uhci_hcd :00:1d.3: FGR not stopped yet! > > uhci_hcd :00:1d.2: FGR not stopped yet! > > uhci_hcd :00:1d.1: FGR not stopped yet! > > uhci_hcd :00:1d.0: FGR not stopped yet! > > > > > Is that "FGR not stopped yet!" messgae new behaviour? > > > > It is a new message since 2.6.24-rc3. I have never try -mm tree before. > > These messages could indicate a timing problem. You can see the code > that writes the messages near the end of wakeup_rh() in > drivers/usb/host/uhci-hcd.c. > > The message gets written if the controller hardware hasn't turned off a > particular bit after a 4-us delay. If the udelay() function wasn't > working right, it could cause this problem. udelay() _is_ OK for 2.6.24-rc3, so it is not the cause of the problem Marin Mitov > > 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Where is the interrupt going?
Hi, On Friday 23 November 2007 02:48:53 am you wrote: > I tried the hammer and the problem persists. > [EMAIL PROTECTED]:~$ cat /proc/cmdline > root=UUID=8b3c3666-22c3-4c04-b399-ece266f2ef30 ro noapic quiet splash > > However, I reserve the right to try the hammer again in the future. > When I look at /proc/interrupts without the APIC: > [EMAIL PROTECTED]:~$ cat /proc/interrupts > CPU0 >0:144XT-PIC-XTtimer >1: 10XT-PIC-XTi8042 >2: 0XT-PIC-XTcascade >5: 10XT-PIC-XTohci_hcd:usb5, mxser >6: 5XT-PIC-XTfloppy >7: 1XT-PIC-XTparport0 >8: 3XT-PIC-XTrtc >9: 1XT-PIC-XTacpi, uhci_hcd:usb2 > 10: 10XT-PIC-XTohci_hcd:usb4, ehci_hcd:usb6, > [EMAIL PROTECTED]::01:00.0 > 11: 2231XT-PIC-XTuhci_hcd:usb1, ohci_hcd:usb3, eth0 > 12:130XT-PIC-XTi8042 > 14: 4362XT-PIC-XTlibata > 15: 15315XT-PIC-XTlibata > NMI: 0 > LOC: 130125 > ERR: 0 > MIS: 0 > > I do not even see the device that I registered unless it is that > r128... line. However the code printed out in /var/log/messages: No, this is your radeon 128 board (on AGP I suppose). Could be integrated on the mobo if it is a server mobo. > Nov 22 16:05:27 bbb kernel: [ 104.712473] apc8620: VID = 0x10B5 > Nov 22 16:05:27 bbb kernel: [ 104.712486] apc8620: mapped addr = e0bd4000 > Nov 22 16:05:27 bbb kernel: [ 104.713022] apc8620: registered carrier 0 > Nov 22 16:05:27 bbb kernel: [ 104.713028] apc8620: interrupt data > (0xe1083e40) on irq (10) and status (0x10) Here is the problem (I suppose): if status (0x10 hex or 16 decimal) is the value returned by request_irq: status = request_irq (apcsi[i].board_irq, apc8620_handler, IRQF_DISABLED, DEVICE_NAME, (void*)&apcsi[i]); (from your first post), that means the irq is NOT registered, because according to the LDD v.3 book: The value returned from request_irq to the requesting function is either 0 to indicate success or a negative error code, as usual. It’s not uncommon for the function to return -EBUSY to signal that another driver is already using the requested interrupt line. If you grep the kernels's include directory for EBUSY you will find: #defineEBUSY 16 /* Device or resource busy */ in include/asm-generic/errno-base.h So I think your mobo has shared (with other devices) irq line on the PCI/PCIe slot you use for your hardware and these other devices have already registered shered irq handlers for the same irq (10), so the attempt to register nonshared irq fails. Either try to register the irq as shared, or put the hardware on another slot whose irq line is not shared with other devises (if such one exists). This info should be available from the mobo manual book. > > which indicates it successfully registered without being shared. No, as I already explained. The only problem :-) in my explanation is: request_irq returns EBUSY (not -EBUSY as should be) Marin Mitov > When > I have more time, I will changed the code to be a shared IRQ and try > the noapic again. > > However, without the noapic /proc/interrupts looks like: > [EMAIL PROTECTED]:~$ cat /proc/interrupts > CPU0 >0:154 IO-APIC-edge timer >1: 10 IO-APIC-edge i8042 >6: 5 IO-APIC-edge floppy >7: 0 IO-APIC-edge parport0 >8: 3 IO-APIC-edge rtc >9: 1 IO-APIC-fasteoi acpi > 10: 0 IO-APIC-edge apc8620 > 12:130 IO-APIC-edge i8042 > 14: 2861 IO-APIC-edge libata > 15: 1049 IO-APIC-edge libata > 16: 11 IO-APIC-fasteoi ohci_hcd:usb5, mxser > 17: 0 IO-APIC-fasteoi uhci_hcd:usb1, ohci_hcd:usb3 > 18: 0 IO-APIC-fasteoi uhci_hcd:usb2 > 19:187 IO-APIC-fasteoi eth0 > 20: 0 IO-APIC-fasteoi ohci_hcd:usb4, [EMAIL > PROTECTED]::01:00.0 > 21: 0 IO-APIC-fasteoi ehci_hcd:usb6 > NMI: 0 > LOC: 8820 > ERR: 0 > MIS: 0 > > > I have attached the kernel module. The apc8620 is an IndustryPack > carrier card. I can therefore open up N (in this specific case 5) sub > memory windows in the memory mapped PCI address. The kernel module > keeps track of the slot offsets from the memory mapped address so that > the user can simply use read and wr
[PATCH]new_TSC_based_delay_tsc()
Hi all,
This is a patch based on the Ingo's idea/patch to track
delay_tsc() migration to another cpu by comparing
smp_processor_id(). It is against kernel-2.6.24-rc3.
What is different:
1. Using unsigned (instead of long) to unify for i386/x86_64.
2. Minimal preempt_disable/enable() critical sections
(more room for preemption)
3. some statements have been rearranged, to account for
possible under/overflow of left/TSC
Tested on both: 32/64 bit SMP PREEMPT kernel-2.6.24-rc3
Hope it is correct. Comments, please.
Signed-off-by: Marin Mitov <[EMAIL PROTECTED]>
=
--- a/arch/x86/lib/delay_32.c 2007-11-18 10:20:45.0 +0200
+++ b/arch/x86/lib/delay_32.c 2007-11-18 10:20:44.0 +0200
@@ -38,18 +38,41 @@
:"0" (loops));
}
-/* TSC based delay: */
+/* TSC based delay:
+ *
+ * We are careful about preemption as TSC's are per-CPU.
+ */
static void delay_tsc(unsigned long loops)
{
- unsigned long bclock, now;
+ unsigned prev, now;
+ unsigned left = loops;
+ unsigned prev_cpu, cpu;
+
+ preempt_disable();
+ rdtscl(prev);
+ prev_cpu = smp_processor_id();
+ preempt_enable();
+ now = prev;
- preempt_disable(); /* TSC's are per-cpu */
- rdtscl(bclock);
do {
rep_nop();
+
+ left -= now - prev;
+ prev = now;
+
+ preempt_disable();
rdtscl(now);
- } while ((now-bclock) < loops);
- preempt_enable();
+ cpu = smp_processor_id();
+ preempt_enable();
+
+ if (prev_cpu != cpu){
+ /*
+* We have migrated, we skip this small amount of time:
+*/
+ prev = now;
+ prev_cpu = cpu;
+ }
+ } while ((now-prev) < left);
}
/*
--- a/arch/x86/lib/delay_64.c 2007-11-18 10:20:44.0 +0200
+++ b/arch/x86/lib/delay_64.c 2007-11-18 10:20:44.0 +0200
@@ -26,18 +26,42 @@
return 0;
}
+/* TSC based delay:
+ *
+ * We are careful about preemption as TSC's are per-CPU.
+ */
void __delay(unsigned long loops)
{
- unsigned bclock, now;
+ unsigned prev, now;
+ unsigned left = loops;
+ unsigned prev_cpu, cpu;
+
+ preempt_disable();
+ rdtscl(prev);
+ prev_cpu = smp_processor_id();
+ preempt_enable();
+ now = prev;
- preempt_disable(); /* TSC's are pre-cpu */
- rdtscl(bclock);
do {
- rep_nop();
+ rep_nop();
+
+ left -= now - prev;
+ prev = now;
+
+ preempt_disable();
rdtscl(now);
+ cpu = smp_processor_id();
+ preempt_enable();
+
+ if (prev_cpu != cpu){
+ /*
+* We have migrated, we skip this small amount of time:
+*/
+prev = now;
+prev_cpu = cpu;
+ }
}
- while ((now-bclock) < loops);
- preempt_enable();
+ while ((now-prev) < left);
}
EXPORT_SYMBOL(__delay);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
is minimum udelay() not respected in preemptible SMP kernel-2.6.23?
Hi all, I have written a linux device driver for a frame grabber I use in my every day experimental work. In my device driver I have to write to a MMIO register, wait for a while (using udelay(65)) for data being written to an internal register (i2c?) and test a flag (in another MMIO register) if the operation has completed. (The hardware guarantees that the operation has completed in less than 65 usec). If the flag is not reset I write a message via printk. After switching to the kernel-2.6.23 (compiled as PREEMPTIBLE SMP i686) (AMD dual core) I see this message in dmesg output sometime. Testing with rdtscll() before and after udelay(65) shows the expected delay of 65 usec (after dividing by CPU frequency) when all is OK, but gives a big value (in the tenths msec range) when the error message shows itself in dmesg. Bracketing udelay(65) by: local_irq_disable(); udelay(65); local_irq_enable(); as well as by preempt_disable(); udelay(65); preempt_enable(); leads to message disappearing. I believe the hardware is working correctly, so if the flag is not reset I think udelay(65) returns prematurely (the flag clears some time latter) And it does not matter if I use udelay(65) or udelay(100). What could be the reason for such a behavior? Is this a bug in udelay() due to preemption? (udelay() being preempted and migrated to another processor) All my previous kernels used were SMP (but not PREEMPTIBLE) My kernel is compiled with: CONFIG_PREEMPT=y CONFIG_IRQBALANCE=y CONFIG_HPET_TIMER=y And I have this line in dmesg: Time: acpi_pm clocksource has been installed. Switched to high resolution mode on CPU 0 Switched to high resolution mode on CPU 1 The south bridge is: VIA VT8237 (Asus A8V Delux) Thank you in advance for your help in understanding where the problem is coming from. Best regards. Marin Mitov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is minimum udelay() not respected in preemptible SMP kernel-2.6.23?
Hi all, Thanks to all of you answering to my post. On 7.11.2007, Andrew Morton wrote: > Ow. Yes, from my reading delay_tsc() can return early (or after > heat-death-of-the-universe) if the TSCs are offset and if preemption > migrates the calling task between CPUs. > > I suppose a lameo fix would be to disable preemption in delay_tsc(). I have seen the problem in delay_tsc(), but I was pusled by these lines in my dmesg: > Time: acpi_pm clocksource has been installed. > Switched to high resolution mode on CPU 0 > Switched to high resolution mode on CPU 1 I thought (sort of) acpi_pm (but not tsc) is used in udelay(). The same delay_tsc() is used in both arches: i386 & x86_64 (and as I see from the proposed patches in -mm, also for the new x86 arch). Should the patch be applied for all of them? Quite similar function ia64_itc_udelay() is used in IA64, but one find a coment before it: /* * Generic udelay assumes that if preemption is allowed and the thread * migrates to another CPU, that the ITC values are synchronized across * all CPUs. */ Are they really synchronized or similar patch: preempt_disable/enable() should be applied? What about all other arches? Thanks. Marin Mitov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
