about an elevator that is being registered, elevator_init() perhaps is the
right place to print what is the chosen/default elevator. But the catch 22 is
that elv_init() is called once for every block device, so I cannot see an
easy solution to print just once.
I will try to think more about it,
--- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> I finally figured out the second issue. Took some time to get that figure
> out. Sorry. But now all the bug reports make sense.
[...]
Impressive Christoph. Indeed, this fixes my problem on latest -git (its hg
equivalent :-)). Well done.
(Tested
Asus M2A-VM board with the most recent BIOS update
AM2 5600
x86-64 kernel
With newer kernels (like 2.6.22-rc4), kernel hangs solid during bootup: no
oops, bug or panic etc. With nohpet kernel parameter, it boots fine.
(I referred to the following threads:
http://marc.info/?l=linux-kernel&w=2&r=1&
--- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Sun, 20 May 2007, Srihari Vijayaraghavan wrote:
>
> > Code: 0f ob eb fe 48 8b 1b 48 8b 0x 0f 18 08 48 81 fb 60 cb 51 80
> > RIP [...] slab_sysfs_init+0x49/0x98
> > RSP [...]
> > kernel panic - not syncing
--- Srihari Vijayaraghavan <[EMAIL PROTECTED]> wrote:
> --- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > On Sun, 20 May 2007, Srihari Vijayaraghavan wrote:
> >
> > > Code: 0f ob eb fe 48 8b 1b 48 8b 0x 0f 18 08 48 81 fb 60 cb 51 80
> > >
--- Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On 5/20/07, Srihari Vijayaraghavan <[EMAIL PROTECTED]>
> wrote:
> > --- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > > On Sun, 20 May 2007, Srihari Vijayaraghavan wrote:
> > >
> > > > Co
Just another data point: with the flick of CONFIG_SMP, I'm in control of the
hangs/crashes ;-).
Yup, with CONFIG_SMP=n, I'm unable to reproduce the problem. It's quite stable
actually (having completed a dozen kernel compile sessions so far).
I suspected this after seeing spinlock issues on both
--- Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Srihari Vijayaraghavan <[EMAIL PROTECTED]> wrote:
> > Yup, with CONFIG_SMP=n, I'm unable to reproduce the problem. It's
> > quite stable actually (having completed a dozen kernel compile
> > s
--- Ingo Molnar <[EMAIL PROTECTED]> wrote:
[...]
> yes - PROVE_LOCKING reactivates spinlocks even on UP. At least this
> suggests that you'd have gotten the hang even with maxcpus=1 - i.e. the
> spinlock corruption is not caused by some genuine SMP race.
You're right on the mark there: even wit
--- Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Tue, 22 May 2007, Srihari Vijayaraghavan wrote:
[...]
> > Compiled slub with SMP & CONFIG_PROVE_LOCKING. No luck. It still hangs
> solid
[...]
> You've made no mention of trying the patch I sent yesterday, or
--- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 23 May 2007, Srihari Vijayaraghavan wrote:
[...]
> Yup. compile with
>
> CONFIG_NUMA
>
> CONFIG_LOCKDEP
>
> CONFIG_DEBUG_LOCK_ALLOCS
(All the tests in this email was conducted on top of your patch)
Yup d
--- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 23 May 2007, Srihari Vijayaraghavan wrote:
>
> > I'm personally very happy that slub works stably without slub debug
> options,
> > because that's what I'd run in a production env. Thanks to your
--- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Thu, 24 May 2007, Srihari Vijayaraghavan wrote:
[...]
> Could you boot with slub_debug and then run
Done.
> slabinfo -v
>
> to validate all slabs? If there is anything wrong with an object then it
> should show
--- Christoph Lameter <[EMAIL PROTECTED]> wrote:
[...]
> You need to be root to do this. Sorry.
Of course, I tried it as root also.
(Kernel hg commit a4c9979b8d42 is 2.6.22-rc2 + all commits available as of a
few minutes ago)
[EMAIL PROTECTED] ~]# whoami
root
[EMAIL PROTECTED] ~]# uname -a
Linu
--- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> slabinfo -v
[...]
> Any corrupted objects will be reported to the syslog.
(Only only could have made that sentence better.)
Sorry I didn't know slabinfo -v produces nothing on stdout, stderr, rather all
findings reported to syslog. Right? You do
[Sorry to reply to my own email, but I had some good development on this
problem]
--- Srihari Vijayaraghavan <[EMAIL PROTECTED]> wrote:
> Here's the first one (there a couple following this;
> the complete dmesg is at the bottom of this email):
It turns out the system is no go
--- Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi Srihari,
Hello Michal,
[...]
> > It turns out the system is no go with 4 GB of RAM (4 * 1 GB modules):
> system
> > instability & SATA controller doesn't detect the drives (as I reported to
> > linux-ide:
> > http://www.mail-archive.com/[EMAI
Here's the first one (there a couple following this;
the complete dmesg is at the bottom of this email):
invalid opcode: [1] SMP
CPU 1
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat
nf_conntrack_ipv4 xt_state
nf_conntrack nfnetlink ipt_REJECT xt_tcpudp
iptable_filter ip_tables x_tables
Hello Folks,
[Thanks for Dmitry for pointing out my error in previous attempts at
sending this email. I've fixed it now. Sorry if you've received this
email multiple times by now.]
Months ago, I raised kernel bugzilla 81331
(https://bugzilla.kernel.org/show_bug.cgi?id=81331) for Linux not
detecti
19 matches
Mail list logo
