[lkml]   [2010]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BUG: using smp_processor_id() in preemptible [00000000] code: icedove-bin/5449
On 25.05.2010 16:13, Piotr Hosowicz wrote:
> On 25.05.2010 12:29, Piotr Hosowicz wrote:
>> On 25.05.2010 12:05, Piotr Hosowicz wrote:
>>> On 25.05.2010 12:00, Peter Zijlstra wrote:
>>>> On Tue, 2010-05-25 at 11:57 +0200, Piotr Hosowicz wrote:
>>>>> On 25.05.2010 11:43, Ingo Molnar wrote:
>>>>>> This doesnt fix the whole issue. cpu_clock() is local, while the
>>>>>> measurements
>>>>>> done in the blk code are global ...
>>>>>> While the warning is fixed this way, the far more serious issue is
>>>>>> still
>>>>>> there: time can go backwards if two points of time measurement are on
>>>>>> different CPUs and can mess up the statistics with negative values,
>>>>>> etc...
>>>>> How serious is this? Can it damage my data? I ask because the
>>>>> machine is
>>>>> my private computer, not any test machine.
>>>> I'm not sure, since I didn't really look what they use the timestamps
>>>> for, but a guess would say your data is safe, it might schedule the io
>>>> funny, but it should not compromise integrity. At best its used purely
>>>> for statistics and not even behaviour is affected.
>>> Thanks.
>> Seems to work like a charm.
> Not exactly. I looked into the syslog. I's much better, but I rebooted
> to single user mode to rebuild nvidia driver (new beta version) and I
> see same error (BUG ... code: ???) on shuting down, mentioning sync,
> umount and finally shutdown.

Sorry, reversed order - shutdown, umount, finally sync.

- Czy jest cukier w kostkach ?
- Nie ma.
- A jakas inna tania bombonierka? Dla tesciowej.
NP: Chickenfoot - Soap On A Rope
NB: 2.6.34-20100524-1752-patched

 \ /
  Last update: 2010-05-25 16:37    [W:0.074 / U:2.928 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site