My fault. The ia64 patch was the
problem.
- Original Message -
From:
Matthew D.
Pitts
To: [EMAIL PROTECTED]
Sent: Thursday, December 28, 2000 4:39
PM
Subject: linux 2.4.0-test12 compile
error
Forgive me if this question has already been
answered. I am
or 1
the kernel I am trying to compile is linux-2.4.0-test12
with linux-2.4.0-test12-ia64-001214 and linux-2.4.0-test12-reiserfs-3.6.23
patches applied. Is there something else I need?
Matthew D. Pitts
[EMAIL PROTECTED]
On Tuesday December 12, [EMAIL PROTECTED] wrote:
>
>
> On Wed, 13 Dec 2000, Neil Brown wrote:
> >
> > Yes... you are right. Alright, I can't escape it any other way so I
> > guess I must admit that it is a raid5 bug.
> >
> > But how can raid5 be calling b_end_io on a buffer_head that was nev
On Tue, Dec 12, 2000 at 07:08:09PM -0800, Linus Torvalds wrote:
> > The following patch disabled that code.
>
> If this fix makes the oops go away, then the proper fix for the problem is
> not the #if 0, but do add something like
Well, this fix did make the oops go away, but it also caused anot
On Wed, 13 Dec 2000, Neil Brown wrote:
>
> Yes... you are right. Alright, I can't escape it any other way so I
> guess I must admit that it is a raid5 bug.
>
> But how can raid5 be calling b_end_io on a buffer_head that was never
> passed to generic_make_request?
> Answer, it snoops on the b
On Tuesday December 12, [EMAIL PROTECTED] wrote:
>
>
> On Wed, 13 Dec 2000, Neil Brown wrote:
> >
> > Could you add this test to the top of md_make_request as well, because
> > requests to raid5 don't go through generic_make_request.
>
> Sure they do. Everything that calls ll_rw_block() or subm
On Wed, 13 Dec 2000, Neil Brown wrote:
>
> Could you add this test to the top of md_make_request as well, because
> requests to raid5 don't go through generic_make_request.
Sure they do. Everything that calls ll_rw_block() or submit_bh() will go
through generic_make_request.
Neil, you're proba
l pointer deref is coming from there
> - Neil, do you have some documentation on how this code should work, as
> stripe_head causes some null-pointer-derefs inside my head..
No, no doco, sorry.
I do have a new version of the code that I haven't been brave enough
to submit during a code freeze
On Tue, Dec 12, 2000 at 11:06:07AM -0800, Linus Torvalds wrote:
> > Dec 12 14:04:50 spaans kernel: invalid operand:
> > Dec 12 14:04:50 spaans kernel: CPU:1
> > Dec 12 14:04:50 spaans kernel: EIP:0010:[end_buffer_io_bad+85/92]
> >
> > Dec 12 14:04:50 spaans kernel: Call Trace:
> >
On Wed, Dec 13, 2000 at 06:56:22AM +1100, Neil Brown wrote:
> Guilt by association :-)
>
> What this bit of code (complete_stripe/raid5_end_buffer_io) is doing
> is observing that it as completed some I/O request that was made of
> the raid5 device and is calling the b_end_io on the buffer_head
On Tuesday December 12, [EMAIL PROTECTED] wrote:
>
>
> On Tue, 12 Dec 2000, Jasper Spaans wrote:
>
> > On Mon, Dec 11, 2000 at 06:52:55PM -0800, Linus Torvalds wrote:
> > >
> > > Ok, there it is. Noticeable changes from pre8 are mainly (a) new tq list
> > > compile fixes and (b) the NetApp sna
On Tue, 12 Dec 2000, Jasper Spaans wrote:
> On Mon, Dec 11, 2000 at 06:52:55PM -0800, Linus Torvalds wrote:
> >
> > Ok, there it is. Noticeable changes from pre8 are mainly (a) new tq list
> > compile fixes and (b) the NetApp snapshot thing.
>
> > - final:
> > - Neil Brown: raid and md c
On Mon, Dec 11, 2000 at 06:52:55PM -0800, Linus Torvalds wrote:
>
> Ok, there it is. Noticeable changes from pre8 are mainly (a) new tq list
> compile fixes and (b) the NetApp snapshot thing.
> - final:
> - Neil Brown: raid and md cleanups
Hmm, while doing some not-so-heavy things with a m
On Tue, 12 Dec 2000, Bill Maidment wrote:
> Hi
>
> I reported a problem with using 'init 1' with 2.4.0-test12-pre8 and was
> told it wasn't a kernel problem. I beg to differ, as it still happens
> with 2.4.0-test12 but not with 2.4.0-test12-pre7. What changed between
> pre7 and pre8 to make 'ini
Hi
I reported a problem with using 'init 1' with 2.4.0-test12-pre8 and was
told it wasn't a kernel problem. I beg to differ, as it still happens
with 2.4.0-test12 but not with 2.4.0-test12-pre7. What changed between
pre7 and pre8 to make 'init 1' behave like 'init 5'? 'init 3' works
correctly. Th
Ok, there it is. Noticeable changes from pre8 are mainly (a) new tq list
compile fixes and (b) the NetApp snapshot thing.
Dave's merge_segments thing could in theory be a deadlock on SMP.
Linus
- final:
- David Miller: sparc and net updates. Fix merge_segments.
-
I have noticed that Linux 2.4.0-test12-pre7 still comes with .8final. Is
there a plan to have .9 incorporated at some future time into the stock
2.4 kernels? Will this happen before 2.4 comes out?
Also is there a transition path between .8final and .9? (short of save
everything to tape and
Hello linux-kernel,
I tried to compile linux-2.4.0-test12-pre5, but it gives two errors:
make[3]: Entering directory `/usr/src/linux-2.4.0-test12-pre5/fs/udf'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test12-pre5/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-ali
Apparently, in linux 2.4.0-test12-pre5,
address_space_operations->writepage went from having two parameters
to just one. fs/udf/inode.c apparently was overlooked in the patch.
Here is the one line change.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Su
Hi!
> Anyway, I do have this machine working now, although not everything is
> to my liking. Unlike older picture-books, for example, this one has a
> WinModem. Ugh. And the sound chip is supported, but only by the
~
> ALSA
> driver (the OSS version is too broken to be used).
Gre
On Sat, 2 Dec 2000, Alan Cox wrote:
>
> > But the camera is cool, and works beautifully (once you get XFree86
> > happy) thanks to Andrew Tridgell. (If I could just coax the X server
> > into giving my a YUV overlay I could play DVD's with this thing).
>
> Start at http://www.core.binghamton
On Sat, 2 Dec 2000, Ion Badulescu wrote:
>
> If it's the same bug that locks up the ATI chipset on my Dell laptop,
> then you can safely enable DPMS if only enable the standby mode,
> not the others (suspend and off). The panel gets turned off anyway,
> even in standby.
Yup, same bug, and yes,
On Fri, Dec 01, 2000 at 09:09:25PM -0800, Linus Torvalds wrote:
> NOTE! Getting the 2.4.x kernel up and running is the easy part. The
> machine also has a very recent ATI Rage Mobility chip in it, and you
> need the newest XFree86 CVS snapshot to make it work (along with a
> one-liner patch from
> Anyway, I do have this machine working now, although not everything is
> to my liking. Unlike older picture-books, for example, this one has a
> WinModem. Ugh. And the sound chip is supported, but only by the ALSA
> driver (the OSS version is too broken to be used).
The OSS ymf_sb legacy dr
On 1 Dec 2000 21:09:25 -0800, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Even then XFree86 does something bad with DPMS, and will lock up the
> graphics chipset when it tries to shut down the flat panel display.
> Solution: don't enable DPMS is XF86Config. That's an XFree86 problem,
> but happ
In article <90a065$5ai$[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>Anyway, I do have this machine working now, although not everything is
>to my liking. Unlike older picture-books, for example, this one has a
>WinModem. Ugh. And the sound chip is supported, but only by the
If I buy one of these machines for testing,
will I be able to upgrade the processor's Code
Morphing Software with the new version when it's
ready? I hear the new CMS code will almost
double the battery life.
Thanks,
Miles
-
To unsubscribe from this list: send the line "unsubscribe linux
In article <[EMAIL PROTECTED]>,
Adam J. Richter <[EMAIL PROTECTED]> wrote:
>
> Well, alas, it appears that linux-2.4.0-test12-pre3 freezes hard
>while reading the base address registers of the first PCI device
>(the "host bridge"). Actually, I think t
Followup to: <[EMAIL PROTECTED]>
By author:"Adam J. Richter" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Well, alas, it appears that linux-2.4.0-test12-pre3 freezes hard
> while reading the base address registers of the first PCI device
>
smeta making sure that this particular
combination would work.
Well, alas, it appears that linux-2.4.0-test12-pre3 freezes hard
while reading the base address registers of the first PCI device
(the "host bridge"). Actually, I think the problem is some kind of
system management int
30 matches
Mail list logo
