> [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
[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 852738f39258deafb3d89c187cb1a4050820d555
[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:
[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 the
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,
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
[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
[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
anymore.
[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
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 switched to
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, but
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
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
[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
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.
[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
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
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.
[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:
[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.
[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 work
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
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 bit
26 matches
Mail list logo
