Re: Bug#611456: Why wishlist?
On Sat, 2011-03-19 at 13:14 +0000, Mark Brown wrote:
> severity 611456 wishlist
> kthxbye
OK, lets keep is as wishlist as you propose. Will it be hanging around
for another three years as bug #468696?
> On Thu, Mar 17, 2011 at 11:17:44PM +0100, Svante Signell wrote:
>
> > Why downgrading this bug report to a wishlist? Due to lack of support
> > for multiple cores?? Take a look at the output of x86info for a
>
> That's a part of it, yes - you've submitted a partial patch which
> doesn't implement enough support to work fully on pretty much all modern
> systems.
Does anybody know how the output looks like on kfreebsd system (which is
in the architecture list of x86info). At least the postinstall script
does not seem to apply to kfreebsd, only to linux. However it is not
conditioned as linux only!
$ cat debian/postinst
#!/bin/sh
set -e
#DEBHELPER#
if [ ! -c /dev/cpu/0/cpuid -a -x /dev/MAKEDEV ]; then
(cd /dev ; ./MAKEDEV cpu )
fi
> > GNU/Linux box with dual cores, especially the last lines! This bug is
> > important due to the support of a new architecture and a patch and from
> > what I've learned regarding severity levels it is important! Prove me
> > wrong and I'll concur.
>
> Please take a reality check here - the code for this leaf package now
> compiles but does not fully run on an architecture which isn't exactly
> likely to be a release candidate in the near future. This doesn't
> strike me as being the most urgent issue ever.
See Michael Bancks reply regarding severity levels.
> > Which are your arguments for kfreebsd, which is one of the
> > supported architectures of x86info?
>
> Note that I downgraded the severity to wishlist. This is different to
> closing the bug. All you're doing by trying to keep the severity of the
> bug inflated is to annoy me.
>
> > Under GNU/Linux:
> ...
> > WARNING: Detected SMP, but unable to access cpuid driver.
> > Used Uniprocessor CPU routines. Results inaccurate.
>
> As the output says the program was unable to access the cpuid driver.
> The cpuid driver requires administrative rights.
I've tried with cpuid.ko loaded, and the output was the same (however
without the WARMING... message as listed above). Does not seem like the
cpuid driver did add anything here (at least for my system).
Reply to: