Hello, everybody! :-)
On 2008-02-03 14:51, Andrew Morton wrote:
> On Sun, 3 Feb 2008 14:35:23 +0700 Igor <[email protected]> wrote:
>> On 02/02/2008, Igor <[email protected]> wrote:
[...]
>> And I've tried linux-2.6.24-rc8-mm1 — it fails even running MDs saying
>> that do_md_run() returning -22.
>
> I'm pretty sure that got fixed, thanks.
>
> I'm trying to get 2.6.24-mm1 out. Maybe tomorrow - please test that, make
> sure that we fixed it.
Yeah, you've fixed it now, MD's are running OK.
Now I can say that both 2.6.24-mm1 and 2.6.24-git11 do NOT "see" any
of mine LVM-2 disks. pvscan, for e.g., finds nothing at all.
Mine system's configuration is LVM-2 on MD (Software RAID); 2.6.24
handles it just fine.
P. S. I'm not subscribed to [email protected] (yet), so
please keep my e-mail address intact :-) when replying.
--
End of message. Next message?
On Mon, 04 Feb 2008 20:16:48 +0700 Igor M Podlesny <[email protected]> wrote:
> Hello, everybody! :-)
>
> On 2008-02-03 14:51, Andrew Morton wrote:
> > On Sun, 3 Feb 2008 14:35:23 +0700 Igor <[email protected]> wrote:
> >> On 02/02/2008, Igor <[email protected]> wrote:
> [...]
> >> And I've tried linux-2.6.24-rc8-mm1 — it fails even running MDs saying
> >> that do_md_run() returning -22.
> >
> > I'm pretty sure that got fixed, thanks.
> >
> > I'm trying to get 2.6.24-mm1 out. Maybe tomorrow - please test that, make
> > sure that we fixed it.
>
> Yeah, you've fixed it now, MD's are running OK.
>
> Now I can say that both 2.6.24-mm1 and 2.6.24-git11 do NOT "see" any
> of mine LVM-2 disks. pvscan, for e.g., finds nothing at all.
You may find that you need to update your lvm userspace tools.
Alasdair? other-dm-people? Did we break^Wchange the userspace interface?
I don't think DM has merged yet, so maybe it was something else.
> Mine system's configuration is LVM-2 on MD (Software RAID); 2.6.24
> handles it just fine.
I guess it would be helpful if you could tell us the version of your lvm
userspace tools, and identify the distro.
> P. S. I'm not subscribed to [email protected] (yet), so
> please keep my e-mail address intact :-) when replying.
Is OK, lots of people are in that situation. We do reply-to-all as a
matter of course.
On 2008-02-04 20:27, Andrew Morton wrote:
> On Mon, 04 Feb 2008 20:16:48 +0700 Igor M Podlesny <[email protected]> wrote:
[...]
>> Now I can say that both 2.6.24-mm1 and 2.6.24-git11 do NOT "see" any
>> of mine LVM-2 disks. pvscan, for e.g., finds nothing at all.
>
> You may find that you need to update your lvm userspace tools.
You're right; I've updated my initrd with fresh lvm
userspace-counterpart and now the problem has been fixed. Sorry for
groundless alert.
Thanks!
--
End of message. Next message?
On Tue, 05 Feb 2008 12:32:11 +0700 Igor M Podlesny <[email protected]> wrote:
> On 2008-02-04 20:27, Andrew Morton wrote:
> > On Mon, 04 Feb 2008 20:16:48 +0700 Igor M Podlesny <[email protected]> wrote:
> [...]
> >> Now I can say that both 2.6.24-mm1 and 2.6.24-git11 do NOT "see" any
> >> of mine LVM-2 disks. pvscan, for e.g., finds nothing at all.
> >
> > You may find that you need to update your lvm userspace tools.
>
> You're right; I've updated my initrd with fresh lvm
> userspace-counterpart and now the problem has been fixed. Sorry for
> groundless alert.
>
No, breakage of a userspace interface is considered a serious regression.
If this was deliberate and utterly unavoidable, well, that's bad but sometimes
these things happen. We do prefer to go through elaborate notification
processes to minimise the disruption, which afaik did not happen here.
If, however, the breakage was was unintentional then we should find the
cause and fix it asap, and backport the fix into 2.6.24.1.
Please tell us what version of the userspace tools you were previously runnning.
Could someone in dm-devel land please get involved?
On 2008-02-05 12:32, Igor M Podlesny wrote:
> On 2008-02-04 20:27, Andrew Morton wrote:
>> On Mon, 04 Feb 2008 20:16:48 +0700 Igor M Podlesny <[email protected]> wrote:
> [...]
>>> Now I can say that both 2.6.24-mm1 and 2.6.24-git11 do NOT "see" any
>>> of mine LVM-2 disks. pvscan, for e.g., finds nothing at all.
>>
>> You may find that you need to update your lvm userspace tools.
>
> You're right; I've updated my initrd with fresh lvm
> userspace-counterpart and now the problem has been fixed. Sorry for
> groundless alert.
>
> Thanks!
But as russian proverb says, trouble never comes alone. :-) NVIDIA's fresh driver
isn't compatible anymore:
1) To have compiled it I had to replace global_flush_tlb() call with
__flush_tlb_all() and still guessing was it(?) a correct replacment at all :-)
2) When loading it emits such messages:
nvidia: Unknown symbol change_page_attr
nvidia: Unknown symbol init_mm
Can it be quick and easy solved?
--
End of message. Next message?
On Tue, 05 Feb 2008 13:28:40 +0700
Igor M Podlesny <[email protected]> wrote:
> On 2008-02-05 12:32, Igor M Podlesny wrote:
> > On 2008-02-04 20:27, Andrew Morton wrote:
> >> On Mon, 04 Feb 2008 20:16:48 +0700 Igor M Podlesny
> >> <[email protected]> wrote:
> > [...]
> >>> Now I can say that both 2.6.24-mm1 and 2.6.24-git11 do NOT
> >>> "see" any of mine LVM-2 disks. pvscan, for e.g., finds nothing at
> >>> all.
> >>
> >> You may find that you need to update your lvm userspace tools.
> >
> > You're right; I've updated my initrd with fresh lvm
> > userspace-counterpart and now the problem has been fixed. Sorry for
> > groundless alert.
> >
> > Thanks!
>
> But as russian proverb says, trouble never comes alone. :-)
> NVIDIA's fresh driver isn't compatible anymore:
>
> 1) To have compiled it I had to replace global_flush_tlb()
> call with __flush_tlb_all() and still guessing was it(?) a correct
> replacment at all :-)
it is not;
>
> 2) When loading it emits such messages:
>
> nvidia: Unknown symbol change_page_attr
> nvidia: Unknown symbol init_mm
>
> Can it be quick and easy solved?
best asked at one of the nvidia forums, not on lkml...
they need to adjust a few API calls, it's not hard work but they need
to do that (their driver isn't open source)
--
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
On 2008-02-05 13:34, Arjan van de Ven wrote:
[...]
>> 1) To have compiled it I had to replace global_flush_tlb()
>> call with __flush_tlb_all() and still guessing was it(?) a correct
>> replacment at all :-)
>
> it is not;
I see, thanks. What would be the correct one? ;-)
>>
>> 2) When loading it emits such messages:
>>
>> nvidia: Unknown symbol change_page_attr
>> nvidia: Unknown symbol init_mm
>>
>> Can it be quick and easy solved?
>
> best asked at one of the nvidia forums, not on lkml...
> they need to adjust a few API calls, it's not hard work but they need
> to do that (their driver isn't open source)
You're right.
--
On Tue, 2008-02-05 at 13:44 +0700, Igor M Podlesny wrote:
> On 2008-02-05 13:34, Arjan van de Ven wrote:
> [...]
> >> 1) To have compiled it I had to replace global_flush_tlb()
> >> call with __flush_tlb_all() and still guessing was it(?) a correct
> >> replacment at all :-)
> >
> > it is not;
>
> I see, thanks. What would be the correct one? ;-)
global_flush_tlb() would be the correct one.
On 2008-02-05 13:53, Zachary Amsden wrote:
> On Tue, 2008-02-05 at 13:44 +0700, Igor M Podlesny wrote:
>> On 2008-02-05 13:34, Arjan van de Ven wrote:
>> [...]
>> >> 1) To have compiled it I had to replace global_flush_tlb()
>> >> call with __flush_tlb_all() and still guessing was it(?) a correct
>> >> replacment at all :-)
>> >
>> > it is not;
>>
>> I see, thanks. What would be the correct one? ;-)
>
> global_flush_tlb() would be the correct one.
>
Looking at the kernel's patch I don't think so:
-void global_flush_tlb(void)
-{
- struct list_head l;
- struct page *pg, *next;
-
- BUG_ON(irqs_disabled());
-
- spin_lock_irq(&cpa_lock);
- list_replace_init(&df_list, &l);
- spin_unlock_irq(&cpa_lock);
- flush_map(&l);
- list_for_each_entry_safe(pg, next, &l, lru) {
- list_del(&pg->lru);
- clear_bit(PG_arch_1, &pg->flags);
- if (PageReserved(pg) || !cpu_has_pse || page_private(pg) != 0)
- continue;
- ClearPagePrivate(pg);
- __free_page(pg);
- }
-}
-
-EXPORT_SYMBOL(global_flush_tlb);
--
On Mon, 04 Feb 2008 22:53:10 -0800
Zachary Amsden <[email protected]> wrote:
>
> On Tue, 2008-02-05 at 13:44 +0700, Igor M Podlesny wrote:
> > On 2008-02-05 13:34, Arjan van de Ven wrote:
> > [...]
> > >> 1) To have compiled it I had to replace
> > >> global_flush_tlb() call with __flush_tlb_all() and still
> > >> guessing was it(?) a correct replacment at all :-)
> > >
> > > it is not;
> >
> > I see, thanks. What would be the correct one? ;-)
>
> global_flush_tlb() would be the correct one.
... except that that function got absorbed into the functions that would otherwise require this guy to be called
(which is a needed step to do more selective clflushes for the specific range rather than wholesale wbinvd's
that flush all 12Mb or your cache while you only need to flush 4Kb... but only the other function knew the exact
range of stuff to flush)
>
--
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
On Mon, Feb 04, 2008 at 09:53:04PM -0800, Andrew Morton wrote:
> Could someone in dm-devel land please get involved?
Vague reports like this are sadly a regular occurrence, and they usually
happen when people don't update their initrd after updating their
kernel. As well as the obvious problems from incompatible modules, some
versions of distros are worse than others, as they foolishly hard-code
device numbers, and a new kernel happens to assign device numbers in a
different sequence breaking everything. Another cause is when the
distro lets the boot script run too early without waiting for the kernel
to discover all the devices necessary. Or sometimes kernel/module
changes mean it no longer sees the devices at all.
Alasdair
--
[email protected]