; > > system slowly stops running. One interesting thing is the "ps"
> > > > > command,
> > > > > it gets stuck like this:
> > > >
> > > > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
> > >
> > > D'oh! I mean 2.6.23-
pages and libhugetlbfs. Small programs like
ls work fine. I tried running Evolution through libhugetlbfs and
the
system slowly stops running. One interesting thing is the ps
command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1
ying with huge pages and libhugetlbfs. Small programs like
> > > > "ls" work fine. I tried running Evolution through libhugetlbfs and the
> > > > system slowly stops running. One interesting thing is the "ps" command,
> > > > it gets stuck like
ot; work fine. I tried running Evolution through libhugetlbfs and the
> > > system slowly stops running. One interesting thing is the "ps" command,
> > > it gets stuck like this:
> >
> > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> D'oh! I mean 2.6
ot; work fine. I tried running Evolution through libhugetlbfs and the
> > > system slowly stops running. One interesting thing is the "ps" command,
> > > it gets stuck like this:
> >
> > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> D'oh! I mean 2.6
Small programs like
> >>> "ls" work fine. I tried running Evolution through libhugetlbfs and the
> >>> system slowly stops running. One interesting thing is the "ps" command,
> >>> it gets stuck like this:
> >> Do you m
tem slowly stops running. One interesting thing is the "ps" command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
Actually fixed just after 2.6.23-rc1:
git describe 5ab3ee7b1cd5c91eb2272764f9d7d
ot; work fine. I tried running Evolution through libhugetlbfs and the
> > > system slowly stops running. One interesting thing is the "ps" command,
> > > it gets stuck like this:
> >
> > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> D'oh! I mean 2.6
; > system slowly stops running. One interesting thing is the "ps" command,
> > it gets stuck like this:
>
> Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
Actually fixed just after 2.6.23-rc1:
thing is the ps command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
Actually fixed just after 2.6.23-rc1:
git describe 5ab3ee7b1cd5c91eb2272764f9d7d1fe4749681e
v2.6.23-rc1-14-g5ab3ee7
Thanks,
Nish
through libhugetlbfs and the
system slowly stops running. One interesting thing is the ps command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
Actually fixed just after 2.6.23-rc1:
git
and the
system slowly stops running. One interesting thing is the ps command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut paste to be
sure:
Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT
. One interesting thing is the ps command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
Actually fixed just after 2.6.23-rc1:
git describe 5ab3ee7b1cd5c91eb2272764f9d7d1fe4749681e
v2.6.23-rc1-14
and the
system slowly stops running. One interesting thing is the ps command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut paste to be
sure:
Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT
and the
system slowly stops running. One interesting thing is the ps command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut paste to be
sure:
Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT
work fine. I tried running Evolution through libhugetlbfs and the
system slowly stops running. One interesting thing is the ps command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut paste
system slowly stops running. One interesting thing is the "ps" command,
> > it gets stuck like this:
>
> Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut & paste to be
sure:
Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed
command,
> it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
> psD 81001e57ed40 0 103558 103483
> 81001f061dc8 0096 81003d8586e8 81001cbadc00
> 0
I was playing with huge pages and libhugetlbfs. Small programs like
"ls" work fine. I tried running Evolution through libhugetlbfs and the
system slowly stops running. One interesting thing is the "ps" command,
it gets stuck like this:
psD 81001e57ed40 0 103558 103483
I was playing with huge pages and libhugetlbfs. Small programs like
ls work fine. I tried running Evolution through libhugetlbfs and the
system slowly stops running. One interesting thing is the ps command,
it gets stuck like this:
psD 81001e57ed40 0 103558 103483
mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
psD 81001e57ed40 0 103558 103483
81001f061dc8 0096 81003d8586e8 81001cbadc00
0006 80537009 0030
interesting thing is the ps command,
it gets stuck like this:
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
D'oh! I mean 2.6.23-rc1-mm1, the 22 was a typo. Cut paste to be
sure:
Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007
x86_64 AMD Athlon(tm) 64 Processor 3400
Andy Whitcroft wrote:
> H. Peter Anvin wrote:
>> Andy Whitcroft wrote:
It definitely sounds like a memory clobber of some sort.
Usual suspects, in addition to the input/output buffers you already
looked at, would be the heap and the stack. Finding where the stack
pointer
Andy Whitcroft wrote:
H. Peter Anvin wrote:
Andy Whitcroft wrote:
It definitely sounds like a memory clobber of some sort.
Usual suspects, in addition to the input/output buffers you already
looked at, would be the heap and the stack. Finding where the stack
pointer lives would be my
H. Peter Anvin wrote:
> Andy Whitcroft wrote:
>>> It definitely sounds like a memory clobber of some sort.
>>>
>>> Usual suspects, in addition to the input/output buffers you already
>>> looked at, would be the heap and the stack. Finding where the stack
>>> pointer lives would be my first,
H. Peter Anvin wrote:
Andy Whitcroft wrote:
It definitely sounds like a memory clobber of some sort.
Usual suspects, in addition to the input/output buffers you already
looked at, would be the heap and the stack. Finding where the stack
pointer lives would be my first, instinctive guess.
Andy Whitcroft wrote:
>>>
>> It definitely sounds like a memory clobber of some sort.
>>
>> Usual suspects, in addition to the input/output buffers you already
>> looked at, would be the heap and the stack. Finding where the stack
>> pointer lives would be my first, instinctive guess.
>
> The
H. Peter Anvin wrote:
> Andy Whitcroft wrote:
>> I think that my debugging says that newsetup got the compressed kernel
>> and decompressor into memory ok and execution passed to it normally.
>> But I cannot figure out where the corruption is coming from. I tried
>> annotating the gzip
H. Peter Anvin wrote:
Andy Whitcroft wrote:
I think that my debugging says that newsetup got the compressed kernel
and decompressor into memory ok and execution passed to it normally.
But I cannot figure out where the corruption is coming from. I tried
annotating the gzip decompressor to see
Andy Whitcroft wrote:
It definitely sounds like a memory clobber of some sort.
Usual suspects, in addition to the input/output buffers you already
looked at, would be the heap and the stack. Finding where the stack
pointer lives would be my first, instinctive guess.
The stack seems to be
On Thu 2007-05-31 22:46:11, Len Brown wrote:
> On Monday 21 May 2007 08:11, Pavel Machek wrote:
> > On Thu 2007-05-17 18:42:43, Len Brown wrote:
> > > > Something similar happened to me on XE3, yes.
> > > >
> > > > (Actual values were different; BIOS specified critical temperature at
> > > > cca
On Mon 2007-06-04 11:02:01, Stefan Seyfried wrote:
> On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote:
>
> > Yes, SuSE enables polling mode by default, but that is just
> > distro specific "value add" that should eventually be fixed.
>
> I will do that for openSUSE FACTORY.
Well, I
On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote:
> Yes, SuSE enables polling mode by default, but that is just
> distro specific "value add" that should eventually be fixed.
I will do that for openSUSE FACTORY.
--
Stefan Seyfried
QA / R Team Mobile Devices| "Any
On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote:
> We need to ignore trip point updates from BIOS, and we need to poll
> thermals when use overrides trip points. That's expected. Plus I've
> yet to see platform actually updating the trip points.
Thinkpad 600, whenever a trip point
On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote:
Yes, SuSE enables polling mode by default, but that is just
distro specific value add that should eventually be fixed.
I will do that for openSUSE FACTORY.
--
Stefan Seyfried
QA / RD Team Mobile Devices| Any
On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote:
We need to ignore trip point updates from BIOS, and we need to poll
thermals when use overrides trip points. That's expected. Plus I've
yet to see platform actually updating the trip points.
Thinkpad 600, whenever a trip point is
On Mon 2007-06-04 11:02:01, Stefan Seyfried wrote:
On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote:
Yes, SuSE enables polling mode by default, but that is just
distro specific value add that should eventually be fixed.
I will do that for openSUSE FACTORY.
Well, I still
On Thu 2007-05-31 22:46:11, Len Brown wrote:
On Monday 21 May 2007 08:11, Pavel Machek wrote:
On Thu 2007-05-17 18:42:43, Len Brown wrote:
Something similar happened to me on XE3, yes.
(Actual values were different; BIOS specified critical temperature at
cca 95C, but hw killed
Andy Whitcroft wrote:
>
> I think that my debugging says that newsetup got the compressed kernel
> and decompressor into memory ok and execution passed to it normally.
> But I cannot figure out where the corruption is coming from. I tried
> annotating the gzip decompressor to see if the input
Andy Whitcroft wrote:
> Mel Gorman wrote:
>> On Wed, 16 May 2007, H. Peter Anvin wrote:
>>
>>> Correction, does *this patch* do it for you?
>>>
>> With these two patches in combination, previously failing machines
>> elm3b6 (x86_64 on test.kernel.org) and a modern x86 built a kernel and
>> booted
Andy Whitcroft wrote:
Mel Gorman wrote:
On Wed, 16 May 2007, H. Peter Anvin wrote:
Correction, does *this patch* do it for you?
With these two patches in combination, previously failing machines
elm3b6 (x86_64 on test.kernel.org) and a modern x86 built a kernel and
booted correctly.
Andy Whitcroft wrote:
I think that my debugging says that newsetup got the compressed kernel
and decompressor into memory ok and execution passed to it normally.
But I cannot figure out where the corruption is coming from. I tried
annotating the gzip decompressor to see if the input and
On Monday 21 May 2007 08:11, Pavel Machek wrote:
> On Thu 2007-05-17 18:42:43, Len Brown wrote:
> > > Something similar happened to me on XE3, yes.
> > >
> > > (Actual values were different; BIOS specified critical temperature at
> > > cca 95C, but hw killed the power at cca 83C. Setting critical
On Monday 21 May 2007 08:11, Pavel Machek wrote:
On Thu 2007-05-17 18:42:43, Len Brown wrote:
Something similar happened to me on XE3, yes.
(Actual values were different; BIOS specified critical temperature at
cca 95C, but hw killed the power at cca 83C. Setting critical trip
Mel Gorman wrote:
> On Wed, 16 May 2007, H. Peter Anvin wrote:
>
>> Correction, does *this patch* do it for you?
>>
>
> With these two patches in combination, previously failing machines
> elm3b6 (x86_64 on test.kernel.org) and a modern x86 built a kernel and
> booted correctly.
>
> elm3b132
rnal source after we've gone and
reset the device?
>
> -Original Message-
> From: Andrew Morton [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 25, 2007 5:00 PM
> To: Greg KH
> Cc: Mattia Dongili; Linux Kernel Mailing List; Hayes, Stuart; David
> Brownell; [EMAIL PR
Brownell; [EMAIL PROTECTED]
Subject: Re: [2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic:
rmmod/0x0001/4568
On Fri, 25 May 2007 14:40:05 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> > Hello,
> >
> &g
[EMAIL PROTECTED] (Joseph Fannin) wrote on 05/26/2007 02:29:07 AM:
> On Fri, May 25, 2007 at 10:28:22PM -0400, Reiner Sailer wrote:
> > On Tue, 22 May 2007 03:25:48 -0400
> > [EMAIL PROTECTED] (Joseph Fannin) wrote:
> >
>
> > > I've been getting this since 2.6.21-rc7-mm1:
>
> >
> > Joseph,
[EMAIL PROTECTED] (Joseph Fannin) wrote on 05/26/2007 02:29:07 AM:
On Fri, May 25, 2007 at 10:28:22PM -0400, Reiner Sailer wrote:
On Tue, 22 May 2007 03:25:48 -0400
[EMAIL PROTECTED] (Joseph Fannin) wrote:
I've been getting this since 2.6.21-rc7-mm1:
Joseph,
thank you
Brownell; [EMAIL PROTECTED]
Subject: Re: [2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic:
rmmod/0x0001/4568
On Fri, 25 May 2007 14:40:05 -0700 Greg KH [EMAIL PROTECTED] wrote:
On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
Hello,
with gregkh-usb-usb-ehci-cpufreq
and
reset the device?
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Friday, May 25, 2007 5:00 PM
To: Greg KH
Cc: Mattia Dongili; Linux Kernel Mailing List; Hayes, Stuart; David
Brownell; [EMAIL PROTECTED]
Subject: Re: [2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling
Mel Gorman wrote:
On Wed, 16 May 2007, H. Peter Anvin wrote:
Correction, does *this patch* do it for you?
With these two patches in combination, previously failing machines
elm3b6 (x86_64 on test.kernel.org) and a modern x86 built a kernel and
booted correctly.
elm3b132 and elm3b132
On Mon 2007-05-28 13:50:36, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 12:58:51PM +0200, Pavel Machek wrote:
>
> > It would happily occur under Windows. You just needed to load machine
> > in a way that cpu stayed ~80C.
>
> So replace the DSDT. All the problems get solved that way.
We are
On Mon, May 28, 2007 at 12:58:51PM +0200, Pavel Machek wrote:
> It would happily occur under Windows. You just needed to load machine
> in a way that cpu stayed ~80C.
So replace the DSDT. All the problems get solved that way.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this
Hi!
> > > Because, as Len has pointed out, you end up with two different ideas
> > > about what the trip points are - the kernel's and the hardware's. That
> > > works fine until some event in the firmware either forcibly
> > > resynchronises the two or makes assumptions about the
Hi!
Because, as Len has pointed out, you end up with two different ideas
about what the trip points are - the kernel's and the hardware's. That
works fine until some event in the firmware either forcibly
resynchronises the two or makes assumptions about the spec-compliance of
On Mon, May 28, 2007 at 12:58:51PM +0200, Pavel Machek wrote:
It would happily occur under Windows. You just needed to load machine
in a way that cpu stayed ~80C.
So replace the DSDT. All the problems get solved that way.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list:
On Mon 2007-05-28 13:50:36, Matthew Garrett wrote:
On Mon, May 28, 2007 at 12:58:51PM +0200, Pavel Machek wrote:
It would happily occur under Windows. You just needed to load machine
in a way that cpu stayed ~80C.
So replace the DSDT. All the problems get solved that way.
We are in the
On Fri, May 25, 2007 at 06:38:15AM +, Pavel Machek wrote:
> Hi!
> > Because, as Len has pointed out, you end up with two different ideas
> > about what the trip points are - the kernel's and the hardware's. That
> > works fine until some event in the firmware either forcibly
> >
Hi!
>
> > I doubt it is impossible, would you mind sharing your knowledge why you
> > think it is impossible or point to some related discussion, pls.
>
> Because, as Len has pointed out, you end up with two different ideas
> about what the trip points are - the kernel's and the hardware's.
Hi!
I doubt it is impossible, would you mind sharing your knowledge why you
think it is impossible or point to some related discussion, pls.
Because, as Len has pointed out, you end up with two different ideas
about what the trip points are - the kernel's and the hardware's. That
On Fri, May 25, 2007 at 06:38:15AM +, Pavel Machek wrote:
Hi!
Because, as Len has pointed out, you end up with two different ideas
about what the trip points are - the kernel's and the hardware's. That
works fine until some event in the firmware either forcibly
resynchronises the
ules linked in: thermal processor dm_mod
> > [2.380288] CPU:0
> > [2.380289] EIP: 0060:[]Not tainted VLI
> > [2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2)
> > [2.380547] EIP is at vsnprintf+0x448/0x5d0
> > [2.380633] eax: 4400d340 e
:0060:[c021c978]Not tainted VLI
[2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2)
[2.380547] EIP is at vsnprintf+0x448/0x5d0
[2.380633] eax: 4400d340 ebx: c348f034 ecx: 4400d340 edx: fffe
[2.380721] esi: c03e0100 edi: 4400d340 ebp: c357ecc0 esp: c357ec68
d VLI
> [ 2.380291] EFLAGS: 00010297 (2.6.22-rc1-mm1 #2)
> [2.380547] EIP is at vsnprintf+0x448/0x5d0
> [2.380633] eax: 4400d340 ebx: c348f034 ecx: 4400d340 edx:
fffe
> [2.380721] esi: c03e0100 edi: 4400d340 ebp: c357ecc0 esp:
c357ec68
> [2.3808
On Fri, 25 May 2007 14:40:05 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> > Hello,
> >
> > with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
> > following BUG:
>
> Thanks for letting me know.
>
> Stuart, any
On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
> Hello,
>
> with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
> following BUG:
Thanks for letting me know.
Stuart, any help here?
thanks,
greg k-h
> [ 459.800033] BUG: scheduling while atomic:
Andrew Morton <[EMAIL PROTECTED]> wrote on 05/22/2007 05:23:05 PM:
> On Tue, 22 May 2007 03:25:48 -0400
> [EMAIL PROTECTED] (Joseph Fannin) wrote:
>
> > This comes a bit after IMA bails out successfully, if that's
relevant:
...
> >
> > [1.708761] ima (ima_init): No TPM chip found(rc =
> > To set it up the user will have to know the parameters and have typed
> > them into the BIOS (if it even has an option for it). I see no problem
>
> Sorry, see no problem which way?
Forcing the user to provide the geometry. Historically that driver dealt
with the main disks the user had.
On Thu, 24 May 2007 15:11:08 -0700,
"Williams, Dan J" <[EMAIL PROTECTED]> wrote:
> --- a/async_tx/async_memcpy.c
> +++ b/async_tx/async_memcpy.c
> @@ -56,6 +56,7 @@ async_memcpy(struct page *dest, struct page *src,
> unsigned int dest_offset,
> int_en) : NULL;
>
> if (tx) {
On Thu, 24 May 2007 15:11:08 -0700,
Williams, Dan J [EMAIL PROTECTED] wrote:
--- a/async_tx/async_memcpy.c
+++ b/async_tx/async_memcpy.c
@@ -56,6 +56,7 @@ async_memcpy(struct page *dest, struct page *src,
unsigned int dest_offset,
int_en) : NULL;
if (tx) { /* run the
To set it up the user will have to know the parameters and have typed
them into the BIOS (if it even has an option for it). I see no problem
Sorry, see no problem which way?
Forcing the user to provide the geometry. Historically that driver dealt
with the main disks the user had. Today
Andrew Morton [EMAIL PROTECTED] wrote on 05/22/2007 05:23:05 PM:
On Tue, 22 May 2007 03:25:48 -0400
[EMAIL PROTECTED] (Joseph Fannin) wrote:
This comes a bit after IMA bails out successfully, if that's
relevant:
...
[1.708761] ima (ima_init): No TPM chip found(rc = -19),
On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
Hello,
with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
following BUG:
Thanks for letting me know.
Stuart, any help here?
thanks,
greg k-h
[ 459.800033] BUG: scheduling while atomic:
On Fri, 25 May 2007 14:40:05 -0700 Greg KH [EMAIL PROTECTED] wrote:
On Mon, May 21, 2007 at 11:44:37AM +0900, Mattia Dongili wrote:
Hello,
with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
following BUG:
Thanks for letting me know.
Stuart, any help here?
(2.6.22-rc1-mm1 #2)
[2.380547] EIP is at vsnprintf+0x448/0x5d0
[2.380633] eax: 4400d340 ebx: c348f034 ecx: 4400d340 edx:
fffe
[2.380721] esi: c03e0100 edi: 4400d340 ebp: c357ecc0 esp:
c357ec68
[2.380810] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Alan Cox wrote:
>> The question I'm asking is: do you think it's better to remove this from
>> hd.c, or do you think it's better to add it back boot code BIOS
>> detection (and take the risk of poking an ST-506 disk with legacy data
>> with parameters which may belong to another disk -- keep in
> The question I'm asking is: do you think it's better to remove this from
> hd.c, or do you think it's better to add it back boot code BIOS
> detection (and take the risk of poking an ST-506 disk with legacy data
> with parameters which may belong to another disk -- keep in mind this
> can
Alan Cox wrote:
> I believe the technical description for the comment is "bullshit" 8)
>
> Almost all MFM controllers and RLL controllers will only run at the
> standard primary and secondary ATA address.
Yes, but that doesn't (necessarily) apply to the controller that is
likely to be the
> > It thus needs fixing not removing.
> >
>
> Opinions, anyone (especially Alan):
>
> http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=commitdiff;h=369f16fdd423d79640c4390915e6ab71189cb497
I believe the technical description for the comment is "bullshit" 8)
Almost all
Alan Cox wrote:
>
> hd.c can drive MFM and RLL disks and drivers/ide cannot. Although it
> really wants burying further down the config tree the ability to read MFM
> and RLL disks when recovering ancient data is useful and people do
> actually use this driver now and then rescuing stuff like
> From: Cornelia Huck [mailto:[EMAIL PROTECTED]
> On Wed, 23 May 2007 10:05:39 +0200,
> Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
>
> > We are trying to get rid of dma-mapping.h, see the last change to
the
> > file with commit 411f0f3edc141a582190d3605cadd1d993abb6df. I don't
think
> > we
Alan Cox wrote:
>>> hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
>>>
On Thu, 2007-05-24 at 15:36 +0100, Matthew Garrett wrote:
> On Thu, May 24, 2007 at 04:16:53PM +0200, Thomas Renninger wrote:
>
> > I doubt it is impossible, would you mind sharing your knowledge why you
> > think it is impossible or point to some related discussion, pls.
>
> Because, as Len has
On Thu, May 24, 2007 at 04:16:53PM +0200, Thomas Renninger wrote:
> I doubt it is impossible, would you mind sharing your knowledge why you
> think it is impossible or point to some related discussion, pls.
Because, as Len has pointed out, you end up with two different ideas
about what the trip
Stripping some CCs, acpi and kernel list should be enough this one goes
to...
On Tue, 2007-05-22 at 01:31 +0100, Matthew Garrett wrote:
> On Tue, May 22, 2007 at 12:42:00AM +0200, Pavel Machek wrote:
> > On Mon 2007-05-21 14:45:53, Matthew Garrett wrote:
> > > So don't do it badly. The advantage
> > hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44aad):
hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
hd.c:(.init.text+0x44aad): undefined
Stripping some CCs, acpi and kernel list should be enough this one goes
to...
On Tue, 2007-05-22 at 01:31 +0100, Matthew Garrett wrote:
On Tue, May 22, 2007 at 12:42:00AM +0200, Pavel Machek wrote:
On Mon 2007-05-21 14:45:53, Matthew Garrett wrote:
So don't do it badly. The advantage of
On Thu, May 24, 2007 at 04:16:53PM +0200, Thomas Renninger wrote:
I doubt it is impossible, would you mind sharing your knowledge why you
think it is impossible or point to some related discussion, pls.
Because, as Len has pointed out, you end up with two different ideas
about what the trip
On Thu, 2007-05-24 at 15:36 +0100, Matthew Garrett wrote:
On Thu, May 24, 2007 at 04:16:53PM +0200, Thomas Renninger wrote:
I doubt it is impossible, would you mind sharing your knowledge why you
think it is impossible or point to some related discussion, pls.
Because, as Len has pointed
Alan Cox wrote:
hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
From: Cornelia Huck [mailto:[EMAIL PROTECTED]
On Wed, 23 May 2007 10:05:39 +0200,
Martin Schwidefsky [EMAIL PROTECTED] wrote:
We are trying to get rid of dma-mapping.h, see the last change to
the
file with commit 411f0f3edc141a582190d3605cadd1d993abb6df. I don't
think
we should
Alan Cox wrote:
hd.c can drive MFM and RLL disks and drivers/ide cannot. Although it
really wants burying further down the config tree the ability to read MFM
and RLL disks when recovering ancient data is useful and people do
actually use this driver now and then rescuing stuff like twenty
It thus needs fixing not removing.
Opinions, anyone (especially Alan):
http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=commitdiff;h=369f16fdd423d79640c4390915e6ab71189cb497
I believe the technical description for the comment is bullshit 8)
Almost all MFM
Alan Cox wrote:
I believe the technical description for the comment is bullshit 8)
Almost all MFM controllers and RLL controllers will only run at the
standard primary and secondary ATA address.
Yes, but that doesn't (necessarily) apply to the controller that is
likely to be the primary
The question I'm asking is: do you think it's better to remove this from
hd.c, or do you think it's better to add it back boot code BIOS
detection (and take the risk of poking an ST-506 disk with legacy data
with parameters which may belong to another disk -- keep in mind this
can permanently
Alan Cox wrote:
The question I'm asking is: do you think it's better to remove this from
hd.c, or do you think it's better to add it back boot code BIOS
detection (and take the risk of poking an ST-506 disk with legacy data
with parameters which may belong to another disk -- keep in mind this
MAIL PROTECTED]
cc
"Andrew Morton" <[EMAIL PROTECTED]>, David
Kleikamp/Austin/[EMAIL PROTECTED], "Linux Kernel Mailing List"
, Shirish S Pargaonkar/Austin/[EMAIL PROTECTED]
Subject
Re: 2.6.22-rc1-mm1 cifs_mount oops
Hi,
I have one problem about this: after the srvT
Hi,
On Wednesday 16 May 2007, Adrian Bunk wrote:
> On Tue, May 15, 2007 at 08:19:14PM -0700, Andrew Morton wrote:
> >...
> > - Added an i386 early-startup development tree, as git-newsetup.patch ("H.
> > Peter Anvin" <[EMAIL PROTECTED]>)
> >...
> > Changes since 2.6.21-mm2:
> >...
> >
1 - 100 of 404 matches
Mail list logo
