> [EMAIL PROTECTED] said:
> > Could you try bisecting it down to the guilty commit using git-bisect?
> > [ the "old" stuff got few hundred commits in 2.6.25 ]
> > Thanks, Bart
Ok, I got this:
852738f39258deafb3d89c187cb1a4050820d555 is first bad commit
commit 852738f39258deafb3d89c187cb1a4050820d
[EMAIL PROTECTED] said:
> Could you try bisecting it down to the guilty commit using git-bisect?
> [ the "old" stuff got few hundred commits in 2.6.25 ]
> Thanks, Bart
Will do. It'll take a while though. Not a fast machine and used by the
household...
/A
--
To unsubscribe from this list: send
Hi!
> So that's using the old IDE drivers.
> And the network and USB are sharing IRQ#11 with each
> other.
>
> If you are going to be using newer kernels like this
> (2.6.23+),
> then you might consider shifting those drives over to
> libata drivers.
Yes, that will probably fix it for him, bu
Hi,
On Saturday 23 February 2008, Anders Eriksson wrote:
>
> [EMAIL PROTECTED] said:
> >> But at this point libata is working much better than the old IDE stuff, and
> >> it really is worth moving things over if you can.
> >
> > Ok, I'll take a stab at that tomorrow. Two things...
>
> Having
[EMAIL PROTECTED] said:
>> But at this point libata is working much better than the old IDE stuff, and
>> it really is worth moving things over if you can.
>
> Ok, I'll take a stab at that tomorrow. Two things...
Having switched to ata_piix i can confirm that smartd doesn't hand the system
any
[EMAIL PROTECTED] said:
> the comment on the very top of drivers/ata says:
> tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
That's the one I was referring to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
Jeff Garzik wrote:
>> If this is the prefered driver these days, maybe it shouldn't be marked
>> experimental in the menu anymore?
>
> It's not marked experimental.
>
the comment on the very top of drivers/ata says:
tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
this is a
Anders Eriksson wrote:
Is smartd prepared to handle /dev/sdX style devices?
Yes. You need to pass "-d ata" to smartd and smartctl, if your scripts
are not already doing so.
If this is the prefered driver these days, maybe it shouldn't be marked
experimental in the menu anymore?
It's not
[EMAIL PROTECTED] said:
> So that's using the old IDE drivers. And the network and USB are sharing
> IRQ#11 with each other.
> If you are going to be using newer kernels like this (2.6.23+), then you
> might consider shifting those drives over to libata drivers.
> This involves a little bit of w
Anders Eriksson wrote:
[EMAIL PROTECTED] said:
The sysrq-e output is probably just standard ext3 journalling unrelated to
the problem... what does dmesg say? lspci? What's your hardware setup?
dmesg ; smartd ; dmesg yields no new entries in dmesg. It seems on disk
accesses are dead. it
[EMAIL PROTECTED] said:
> The sysrq-e output is probably just standard ext3 journalling unrelated to
> the problem... what does dmesg say? lspci? What's your hardware setup?
dmesg ; smartd ; dmesg yields no new entries in dmesg. It seems on disk
accesses are dead. it still routes packets
Anders Eriksson wrote:
Hi,
Trying out 2.6.25-rc2 smartd always causes my box to hang. I can switch
vt:s and the keyboard seems to work.
Using sysrq-e I noticed a callpath open -> ext3 -> journals -> sync_buffer ->
io_scheduel -> generic_unplig_device.
I'd guess the open stems from smartd.
Hi,
Trying out 2.6.25-rc2 smartd always causes my box to hang. I can switch
vt:s and the keyboard seems to work.
Using sysrq-e I noticed a callpath open -> ext3 -> journals -> sync_buffer ->
io_scheduel -> generic_unplig_device.
I'd guess the open stems from smartd. Removing smartd from the s
13 matches
Mail list logo