On Mon, Jan 28, 2008 at 08:31:57PM -0500, Gene Heskett wrote:
>
> In my script, its one line:
> mkinitrd -f initrd-$VER.img $VER && \
>
> where $VER is the shell variable I edit to = the version number, located at
> the top of the script.
>
> Unforch, its failing:
> No module pata_amd found
On Mon, Jan 28, 2008 at 08:31:57PM -0500, Gene Heskett wrote:
In my script, its one line:
mkinitrd -f initrd-$VER.img $VER \
where $VER is the shell variable I edit to = the version number, located at
the top of the script.
Unforch, its failing:
No module pata_amd found for kernel
On Wed, Apr 18, 2007 at 03:39:25PM -0400, Len Brown wrote:
> On Sunday 15 April 2007 11:50, Michal Jaegermann wrote:
> >
> > A kernel derived from 2.6.21-rc6-git1 (2.6.20-1.3053.fc7.x86_64 from
> > Fedora "rawhide" to be more precise) did boot on the hardware in
On Wed, Apr 18, 2007 at 03:39:25PM -0400, Len Brown wrote:
On Sunday 15 April 2007 11:50, Michal Jaegermann wrote:
A kernel derived from 2.6.21-rc6-git1 (2.6.20-1.3053.fc7.x86_64 from
Fedora rawhide to be more precise) did boot on the hardware in
question, though; but only when I gave
On Fri, Apr 13, 2007 at 03:38:18PM +0400, Denis Kirjanov wrote:
> I updated the BIOS to the latest version, but the problem persists.
> Boots option pci = noacpi not solved the problem. Reporting bios bug
> disappears when setting pci = nommconf, But the kernel is still not
> loaded (
On x86_64
On Fri, Apr 13, 2007 at 03:38:18PM +0400, Denis Kirjanov wrote:
I updated the BIOS to the latest version, but the problem persists.
Boots option pci = noacpi not solved the problem. Reporting bios bug
disappears when setting pci = nommconf, But the kernel is still not
loaded (
On x86_64
On Sat, Mar 31, 2007 at 05:01:23PM +0200, Adrian Bunk wrote:
> On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> > On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> > >
> > > Subject: kernels fail to boot with
On Sat, Mar 31, 2007 at 05:01:23PM +0200, Adrian Bunk wrote:
On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
Subject: kernels fail to boot with drives on ATIIXP controller
(ACPI/IRQ
ml/2007/3/4/257
> Submitter : Michal Jaegermann <[EMAIL PROTECTED]>
> Status : unknown
I have now even better one with pata_via. A kernel, which for
all practical purposes is 2.6.21-rc5, not only refuses to boot
(and I cannot find some option combination which would allow me to
do so
: Michal Jaegermann [EMAIL PROTECTED]
Status : unknown
I have now even better one with pata_via. A kernel, which for
all practical purposes is 2.6.21-rc5, not only refuses to boot
(and I cannot find some option combination which would allow me to
do so anyway) but simply refuses to read _any_
a.redhat.com/bugzilla/show_bug.cgi?id=229621
> Submitter : Michal Jaegermann <[EMAIL PROTECTED]>
> Status : unknown
Alan added comment to my posting that my problems are caused by
messed up IRQ routing on that box I tried. Indeed, I can boot
kernel 2.6.20-1.2962.fc7, which really i
/show_bug.cgi?id=229621
Submitter : Michal Jaegermann [EMAIL PROTECTED]
Status : unknown
Alan added comment to my posting that my problems are caused by
messed up IRQ routing on that box I tried. Indeed, I can boot
kernel 2.6.20-1.2962.fc7, which really is 2.6.21-rc2, provided
I will use
On Thu, Mar 01, 2007 at 08:33:17PM -0500, Jeff Garzik wrote:
>
> That little change, buried in the middle of Alan's patch, changes the
> probing order for a /lot/ of devices, possibly millions, when you
> consider that it changes behavior of ata_piix (Intel SATA) as well as
> all the
On Thu, Mar 01, 2007 at 08:33:17PM -0500, Jeff Garzik wrote:
That little change, buried in the middle of Alan's patch, changes the
probing order for a /lot/ of devices, possibly millions, when you
consider that it changes behavior of ata_piix (Intel SATA) as well as
all the
On Mon, Dec 04, 2006 at 11:10:01AM +0100, Tobias Oed wrote:
> Tomasz Chmielewski wrote:
>
> > Yes, something's using that drive, be it a program, a module (unlikely),
> > or something that is compiled directly in the kernel (for example,
> > md/raid1).
>
> Since you mention md, dm comes to mind.
On Mon, Dec 04, 2006 at 11:10:01AM +0100, Tobias Oed wrote:
Tomasz Chmielewski wrote:
Yes, something's using that drive, be it a program, a module (unlikely),
or something that is compiled directly in the kernel (for example,
md/raid1).
Since you mention md, dm comes to mind. I have
On Tue, Jul 05, 2005 at 02:57:40PM -0700, Greg KH wrote:
> On Tue, Jul 05, 2005 at 03:50:43PM -0600, Zan Lynx wrote:
> > Sourced from here:
> > http://hulllug.principalhosting.net/archive/index.php/t-52440.html
>
> No, that is not the same topic or thread.
Formally you are correct but from my
On Tue, Jul 05, 2005 at 02:57:40PM -0700, Greg KH wrote:
On Tue, Jul 05, 2005 at 03:50:43PM -0600, Zan Lynx wrote:
Sourced from here:
http://hulllug.principalhosting.net/archive/index.php/t-52440.html
No, that is not the same topic or thread.
Formally you are correct but from my POV this
On Sun, Jul 03, 2005 at 10:44:41PM -0700, Greg KH wrote:
> On Sun, Jul 03, 2005 at 05:12:02PM -0600, Michal Jaegermann wrote:
>
> > Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then
> > what considerations dictated it, other then the patch author wrote
> &g
On Sun, Jul 03, 2005 at 10:44:41PM -0700, Greg KH wrote:
On Sun, Jul 03, 2005 at 05:12:02PM -0600, Michal Jaegermann wrote:
Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then
what considerations dictated it, other then the patch author wrote
it that way, and what drivers
On Mon, Jun 25, 2001 at 12:20:40AM +0200, Daniel Phillips wrote:
> On Sunday 24 June 2001 12:36, Rob Landley wrote:
> > On Saturday 23 June 2001 22:47, Eric W. Biederman wrote:
> > > GEM was a gui from Digital Research I believe.
> > > Geoworks/Geos was a seperate entity.
> >
> > Ah, the DR-DOS
On Mon, Jun 25, 2001 at 12:20:40AM +0200, Daniel Phillips wrote:
On Sunday 24 June 2001 12:36, Rob Landley wrote:
On Saturday 23 June 2001 22:47, Eric W. Biederman wrote:
GEM was a gui from Digital Research I believe.
Geoworks/Geos was a seperate entity.
Ah, the DR-DOS answer to
Here are some small, but in times important, "gotchas" in current
2.4.5-ac kernels.
When compiling SMP 'udelay' in current drivers/pci/quirks.c expands to:
__udelay((15), cpu_data[(current->processor)]...
and a type for 'current' is not known, at least on alpha, so
the following seems to be
Here are some small, but in times important, gotchas in current
2.4.5-ac kernels.
When compiling SMP 'udelay' in current drivers/pci/quirks.c expands to:
__udelay((15), cpu_data[(current-processor)]...
and a type for 'current' is not known, at least on alpha, so
the following seems to be in
A tulip driver 0.9.15-pre3, as included in 2.4.5-ac8, still does not
work for me and I have to replace it with 0.9.14d (April 3, 2001) to
get a functional network.
Trying it with 'tulip_debug=3' option I see this:
Linux Tulip driver version 0.9.15-pre3 (June 1, 2001)
00:0b.0: MWI config mwi=0,
A tulip driver 0.9.15-pre3, as included in 2.4.5-ac8, still does not
work for me and I have to replace it with 0.9.14d (April 3, 2001) to
get a functional network.
Trying it with 'tulip_debug=3' option I see this:
Linux Tulip driver version 0.9.15-pre3 (June 1, 2001)
00:0b.0: MWI config mwi=0,
I mentioned that before but this should be stated clearly. As far as I
am concerned "Linux Tulip driver version 0.9.15-pre2 (May 16, 2001)",
as used in 2.4.5 - and other kernels - is totally buggered. It comes up,
and ethernet interfaces can be configured, but does not matter how I am
playing
I mentioned that before but this should be stated clearly. As far as I
am concerned Linux Tulip driver version 0.9.15-pre2 (May 16, 2001),
as used in 2.4.5 - and other kernels - is totally buggered. It comes up,
and ethernet interfaces can be configured, but does not matter how I am
playing
On Fri, May 25, 2001 at 02:50:07PM -0700, Jay Thorne wrote:
> [1.] One line summary of the problem:
> Kernel 2.4.4 ac15
> Using a quad 400Mhz Dodge/Rawhide machine with Tulip or VIARhine cards,
[ description of a slowdown skipped ].
Well, it looks that you have at least something to
Patches to drivers/scsi/sg.c included in 2.4.4-ac17 require for
'sg.o' module to use 'simple_strtol' which is not exported in
kernel/ksyms.c. Is this is an oversight or 'sg.o' should be actually
using something like 'simple_strtoul' - which is already exported?
In either case patches are
Patches to drivers/scsi/sg.c included in 2.4.4-ac17 require for
'sg.o' module to use 'simple_strtol' which is not exported in
kernel/ksyms.c. Is this is an oversight or 'sg.o' should be actually
using something like 'simple_strtoul' - which is already exported?
In either case patches are
On Fri, May 25, 2001 at 02:50:07PM -0700, Jay Thorne wrote:
[1.] One line summary of the problem:
Kernel 2.4.4 ac15
Using a quad 400Mhz Dodge/Rawhide machine with Tulip or VIARhine cards,
[ description of a slowdown skipped ].
Well, it looks that you have at least something to slow
On Mon, May 21, 2001 at 05:18:55PM +0200, Jan-Benedict Glaw wrote:
>
> Kernel 2.4.5-pre[34] don't compile on Alpha:
>
> 152 struct pci_controller *hose = pdev->sysdata;
^^^
This is the problem (a type for 'pdev' is not
On Mon, May 21, 2001 at 05:18:55PM +0200, Jan-Benedict Glaw wrote:
Kernel 2.4.5-pre[34] don't compile on Alpha:
152 struct pci_controller *hose = pdev-sysdata;
^^^
This is the problem (a type for 'pdev' is not defined).
And
It looks like tha 8139too, at least in 2.2.19, works fine when there
is one such card around but with NICs it detects both but fails to
set the second one correctly (complaints about incorrect IRQ, memory,
... - you name it). Does anybody has some ideas what is going on here?
This was observed
It looks like tha 8139too, at least in 2.2.19, works fine when there
is one such card around but with NICs it detects both but fails to
set the second one correctly (complaints about incorrect IRQ, memory,
... - you name it). Does anybody has some ideas what is going on here?
This was observed
On Thu, May 03, 2001 at 03:47:55AM -0400, Eric S. Raymond wrote:
> OK, so you want CML2's "make oldconfig" to do something more graceful than
> simply say "Foo! You violated this constraint! Go fix it!"
After all this combinatorics I still do not know an answer to a simple
question. With the
On Thu, May 03, 2001 at 03:47:55AM -0400, Eric S. Raymond wrote:
OK, so you want CML2's make oldconfig to do something more graceful than
simply say Foo! You violated this constraint! Go fix it!
After all this combinatorics I still do not know an answer to a simple
question. With the current
On Tue, May 01, 2001 at 10:28:35PM +0100, Alan Cox wrote:
>
> 2.4.4-ac3
Does not compile on Alpha. I have a strange feeling that because
of this:-)
> o Fix module exception race on Alpha (Andrea Arcangeli)
A declaration was forgotten and, comparing with i386
On Tue, May 01, 2001 at 10:28:35PM +0100, Alan Cox wrote:
2.4.4-ac3
Does not compile on Alpha. I have a strange feeling that because
of this:-)
o Fix module exception race on Alpha (Andrea Arcangeli)
A declaration was forgotten and, comparing with i386
On Tue, Apr 24, 2001 at 06:56:32PM +0200, Christian Ehrhardt wrote:
> On Tue, Apr 24, 2001 at 09:10:07AM -0700, Linus Torvalds wrote:
> > ptrace only operates on processes that are stopped. So there are no
> > locking issues - we've synchronized on a much higher level than a
> > spinlock or
On Tue, Apr 24, 2001 at 06:56:32PM +0200, Christian Ehrhardt wrote:
On Tue, Apr 24, 2001 at 09:10:07AM -0700, Linus Torvalds wrote:
ptrace only operates on processes that are stopped. So there are no
locking issues - we've synchronized on a much higher level than a
spinlock or semaphore.
On Thu, Apr 19, 2001 at 11:05:03AM -0500, Victor Zandy wrote:
>
> We have found that one of our programs can cause system-wide
> corruption of the x86 FPU under 2.2.16 and 2.2.17.
>
> We see this problem on dual 550MHz Xeons with 1GB RAM.
Hm, I started to wonder if this is not somewhat
On Thu, Apr 19, 2001 at 11:05:03AM -0500, Victor Zandy wrote:
We have found that one of our programs can cause system-wide
corruption of the x86 FPU under 2.2.16 and 2.2.17.
We see this problem on dual 550MHz Xeons with 1GB RAM.
Hm, I started to wonder if this is not somewhat related
On Mon, Apr 02, 2001 at 05:39:19PM -0700, David Lang wrote:
>
> if the distro/sysadmin _always_ installs the kernel the 'right way' then
> the difference isn't nessasarily that large, but if you want reliability
> on any system it may be worth loosing a page or so of memory (hasn't
> someone
On Mon, Apr 02, 2001 at 05:39:19PM -0700, David Lang wrote:
if the distro/sysadmin _always_ installs the kernel the 'right way' then
the difference isn't nessasarily that large, but if you want reliability
on any system it may be worth loosing a page or so of memory (hasn't
someone said
On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote:
...
>
> 2.4.2-ac20
...
> o Fix Alpha build (Jeff Garzik)
Now I see (at least on Alpha) a constant wailing:
/linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct
mm_struct' declared inside
On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote:
...
2.4.2-ac20
...
o Fix Alpha build (Jeff Garzik)
Now I see (at least on Alpha) a constant wailing:
/linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct
mm_struct' declared inside
On Sat, Mar 10, 2001 at 07:50:06PM +0100, Martin Mares wrote:
> Hello!
>
> > Well, not really in this situation, after a simple modification. It is
> > trivial to show that using "shorter interval sorted first" approach one
> > can bound an amount of an extra memory, on stack or otherwise, and
On Sat, Mar 10, 2001 at 07:50:06PM +0100, Martin Mares wrote:
Hello!
Well, not really in this situation, after a simple modification. It is
trivial to show that using "shorter interval sorted first" approach one
can bound an amount of an extra memory, on stack or otherwise, and by a
On Fri, Mar 09, 2001 at 12:52:22PM +0100, Rogier Wolff wrote:
>
> Quicksort however is an algorithm that is recursive. This means that
> it can use unbounded amounts of stack -> This is not for the kernel.
Well, not really in this situation, after a simple modification. It is
trivial to show
On Fri, Mar 09, 2001 at 12:52:22PM +0100, Rogier Wolff wrote:
Quicksort however is an algorithm that is recursive. This means that
it can use unbounded amounts of stack - This is not for the kernel.
Well, not really in this situation, after a simple modification. It is
trivial to show that
On Sun, Mar 04, 2001 at 02:02:38PM -0600, Matthew Fredrickson wrote:
> On Sun, Mar 04, 2001 at 08:08:32PM +0100, Erik Mouw wrote:
> > Have a look at OpenBIOS:
> >
> > http://www.freiburg.linux.de/OpenBIOS/
> >
> > The project wants to create an IEEE 1275-1994 compliant firmware, like
> > used
On Sun, Mar 04, 2001 at 02:02:38PM -0600, Matthew Fredrickson wrote:
On Sun, Mar 04, 2001 at 08:08:32PM +0100, Erik Mouw wrote:
Have a look at OpenBIOS:
http://www.freiburg.linux.de/OpenBIOS/
The project wants to create an IEEE 1275-1994 compliant firmware, like
used by SUN (for
On Wed, Feb 28, 2001 at 10:54:15PM +, Petr Vandrovec wrote:
> On 28 Feb 01 at 13:46, Michal Jaegermann wrote:
> > I think that I found what gives me a hell with this box and it
> > looks like that this not Linux at all. Once again, this is Athlon
> > K6 on Asus AV7 mob
I think that I found what gives me a hell with this box and it
looks like that this not Linux at all. Once again, this is Athlon
K6 on Asus AV7 mobo and "Award Advanced ACPI BIOS" version 1005C.
I have more checks to make before I will be fully satisfied but
this looks like it.
In this BIOS
I think that I found what gives me a hell with this box and it
looks like that this not Linux at all. Once again, this is Athlon
K6 on Asus AV7 mobo and "Award Advanced ACPI BIOS" version 1005C.
I have more checks to make before I will be fully satisfied but
this looks like it.
In this BIOS
On Wed, Feb 28, 2001 at 10:54:15PM +, Petr Vandrovec wrote:
On 28 Feb 01 at 13:46, Michal Jaegermann wrote:
I think that I found what gives me a hell with this box and it
looks like that this not Linux at all. Once again, this is Athlon
K6 on Asus AV7 mobo and "Award Advanced
After I booted 2.2.19pre14 on a system with two via-rhine cards I see the
following:
via-rhine.c:v1.08b-LK1.0.0 12/14/2000 Written by Donald Becker
http://www.scyld.com/network/via-rhine.html
eth0: VIA VT3043 Rhine at 0x9400, 00:50:ba:c1:64:d9, IRQ 0.
eth0: MII PHY found at address 8, status
To add to my report about troubles with disk activity on a system with
PDC20265 IDE controller (this is on Asus AV7 mobo, BTW) I tried the
same experiments with 2.2.19pre14 patched with ide patches to get a
support for Promise.
I got similar results - i.e. problems after some 130-150 megabytes
To add to my report about troubles with disk activity on a system with
PDC20265 IDE controller (this is on Asus AV7 mobo, BTW) I tried the
same experiments with 2.2.19pre14 patched with ide patches to get a
support for Promise.
I got similar results - i.e. problems after some 130-150 megabytes
After I booted 2.2.19pre14 on a system with two via-rhine cards I see the
following:
via-rhine.c:v1.08b-LK1.0.0 12/14/2000 Written by Donald Becker
http://www.scyld.com/network/via-rhine.html
eth0: VIA VT3043 Rhine at 0x9400, 00:50:ba:c1:64:d9, IRQ 0.
eth0: MII PHY found at address 8, status
I have right now on hands a system with PDC20265 controller, not used
as "raid", and it gives me a hard time. It looks like that after some
number of megabytes copied to a disk, where "number" seems to be
somewhere between 100 and 150, something in a kernel internal structures
get overwritten
I have right now on hands a system with PDC20265 controller, not used
as "raid", and it gives me a hard time. It looks like that after some
number of megabytes copied to a disk, where "number" seems to be
somewhere between 100 and 150, something in a kernel internal structures
get overwritten
On Thu, Feb 15, 2001 at 03:15:01PM -0500, John Jasen wrote:
>
> I retried the mysticism and incantations (d -l 801feac d) at the srm
> prompt, and the machine locked on fsck, under kernel 2.4.1-ac13.
Like I wrote - I did not get to locks on fsck but then stuff was weird
and if I would press
On Thu, Feb 15, 2001 at 12:49:29PM -0500, John Jasen wrote:
>
> Well, the situation is improving, I suppose ...
>
> Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
> the system to go technicolor and lock up.
On UP1100 which I have here somehow this looks a bit different
On Thu, Feb 15, 2001 at 12:49:29PM -0500, John Jasen wrote:
Well, the situation is improving, I suppose ...
Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
the system to go technicolor and lock up.
On UP1100 which I have here somehow this looks a bit different
On Thu, Feb 15, 2001 at 03:15:01PM -0500, John Jasen wrote:
I retried the mysticism and incantations (d -l 801feac d) at the srm
prompt, and the machine locked on fsck, under kernel 2.4.1-ac13.
Like I wrote - I did not get to locks on fsck but then stuff was weird
and if I would press
To follow my own message about lockups on UP1100. This time I tried
to boot 2.4.1-ac1. Results are really the same but this time
an attempt to copy kernel source from a partition on a SCSI drive
to another one on an IDE drive brought different message. I include
it below.
When trying to
On Thu, Feb 01, 2001 at 10:46:12AM -0500, John Jasen wrote:
> On Wed, 31 Jan 2001, Michal Jaegermann wrote:
>
> > I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine
> > happens to have two SCSI disks on sym53c875 controller and two IDE
> > drives h
On Thu, Feb 01, 2001 at 10:46:12AM -0500, John Jasen wrote:
On Wed, 31 Jan 2001, Michal Jaegermann wrote:
I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine
happens to have two SCSI disks on sym53c875 controller and two IDE
drives hooked to a builtin "Acer Laboratorie
To follow my own message about lockups on UP1100. This time I tried
to boot 2.4.1-ac1. Results are really the same but this time
an attempt to copy kernel source from a partition on a SCSI drive
to another one on an IDE drive brought different message. I include
it below.
When trying to
I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine
happens to have two SCSI disks on sym53c875 controller and two IDE
drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE".
It boots and in the first moment makes even a pretty good impression
of beeing healthy. But an
I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine
happens to have two SCSI disks on sym53c875 controller and two IDE
drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE".
It boots and in the first moment makes even a pretty good impression
of beeing healthy. But an
With an SMP kernel one gets, in particular,
depmod: *** Unresolved symbols in /lib/modules/2.2.18pre24/misc/agpgart.o
depmod: smp_call_function
depmod: smp_num_cpus
The machine affected is actually Alpha but likely this is not relevant.
Michal
[EMAIL PROTECTED]
-
To
With an SMP kernel one gets, in particular,
depmod: *** Unresolved symbols in /lib/modules/2.2.18pre24/misc/agpgart.o
depmod: smp_call_function
depmod: smp_num_cpus
The machine affected is actually Alpha but likely this is not relevant.
Michal
[EMAIL PROTECTED]
-
To
I was busy with other things and did not track 2.2.18pre kernels very
carefuly, but now I tried 2.2.18pre23 on Alpha and got an impression
that a situation with a virtual memory handling is worse than it was,
say, in 2.2.18pre15. I can now see in /var/log/messages entries like
"VM: killing
I was busy with other things and did not track 2.2.18pre kernels very
carefuly, but now I tried 2.2.18pre23 on Alpha and got an impression
that a situation with a virtual memory handling is worse than it was,
say, in 2.2.18pre15. I can now see in /var/log/messages entries like
"VM: killing
On Tue, Nov 21, 2000 at 10:47:20AM -0800, Richard Henderson wrote:
> On Tue, Nov 21, 2000 at 06:46:09PM +0300, Ivan Kokshaysky wrote:
> >Interesting, other pyxis machines do not seem to be so sensitive,
> >so I guess some design problems with ux164 motherboard - all this
> >looks
On Tue, Nov 21, 2000 at 10:47:20AM -0800, Richard Henderson wrote:
On Tue, Nov 21, 2000 at 06:46:09PM +0300, Ivan Kokshaysky wrote:
Interesting, other pyxis machines do not seem to be so sensitive,
so I guess some design problems with ux164 motherboard - all this
looks pretty much
On Tue, Nov 21, 2000 at 12:53:04AM +1030, Alan Kennington wrote:
>
> I still think that write_null() should be rewritten as:
>
> ===
> static ssize_t write_null(struct file * file, const char * buf,
> size_t count, loff_t
On Tue, Nov 21, 2000 at 12:53:04AM +1030, Alan Kennington wrote:
I still think that write_null() should be rewritten as:
===
static ssize_t write_null(struct file * file, const char * buf,
size_t count, loff_t
At least on Alpha, and possibly other architectures, the following
minor correction is needed:
--- linux-2.4.0p11p/include/asm-alpha/semaphore.h~ Mon Nov 13 14:01:10 2000
+++ linux-2.4.0p11p/include/asm-alpha/semaphore.h Mon Nov 13 14:03:44 2000
@@ -11,6 +11,7 @@
#include
#include
At least on Alpha, and possibly other architectures, the following
minor correction is needed:
--- linux-2.4.0p11p/include/asm-alpha/semaphore.h~ Mon Nov 13 14:01:10 2000
+++ linux-2.4.0p11p/include/asm-alpha/semaphore.h Mon Nov 13 14:03:44 2000
@@ -11,6 +11,7 @@
#include
On Sun, Nov 12, 2000 at 10:09:39PM -0500, Jeff Garzik wrote:
> [EMAIL PROTECTED] wrote:
> > 4. Boot Time Failures
>
> > * Various Alpha's don't boot under 2.4.0-test9 (PCI-PCI bridges are
> >not configured correctly Michal Jaegermann; Richard Henderson may
On Sun, Nov 12, 2000 at 10:09:39PM -0500, Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
4. Boot Time Failures
* Various Alpha's don't boot under 2.4.0-test9 (PCI-PCI bridges are
not configured correctly Michal Jaegermann; Richard Henderson may
have an idea what's
On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote:
> > It was posted to lkml, so no link (except if you want to dig through
> > lkml mail archives).
>
> It booted but then it oops'ed before userland I belive. I tried it this
> morning and didn't have much time. It did find the scsi
On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote:
It was posted to lkml, so no link (except if you want to dig through
lkml mail archives).
It booted but then it oops'ed before userland I belive. I tried it this
morning and didn't have much time. It did find the scsi
I complained few days ago that 'agpgart.o' module from 2.2.18pre
is causing a kernel oops. The problem turned out to be an apparent
assumption that PCI memory <-> memory mapping is an identity and
this is not always the case.
Here is a patch applicable to all 2.2.18pre kernels with agpgart
I complained few days ago that 'agpgart.o' module from 2.2.18pre
is causing a kernel oops. The problem turned out to be an apparent
assumption that PCI memory - memory mapping is an identity and
this is not always the case.
Here is a patch applicable to all 2.2.18pre kernels with agpgart
On UP1100 Alpha with an AGP slot and "Advanced Micro Devices [AMD]
AMD-751 [Irongate] System Controller" an attempt to use 'agpgart'
support ends up with an oops. I tried 2.2.17 and 2.2.18pre15 kernels.
With CONFIG_AGP=y and CONFIG_AGP_AMD=y resulting kernel gets stuck
after oops and does not
> Somewhere floating around there is a perl version of rpm2cpio.
This is what I wrote one day a long time ago:
#!/usr/bin/perl -w
use strict;
my ($buffer, $pos, $gzmagic);
$gzmagic = "\037\213";
open OUT, "| gunzip" or die "cannot find gunzip; $!\n";
while(1) {
exit 1 unless defined($pos =
Somewhere floating around there is a perl version of rpm2cpio.
This is what I wrote one day a long time ago:
#!/usr/bin/perl -w
use strict;
my ($buffer, $pos, $gzmagic);
$gzmagic = "\037\213";
open OUT, "| gunzip" or die "cannot find gunzip; $!\n";
while(1) {
exit 1 unless defined($pos =
An attempt to use on Alpha UX a 'trident' module on 2.2.18pre15 (and
2.2.17, and 2.2.16 with patches) with a sound card present ends up
with the following lines in 'dmesg':
Trident 4DWave/SiS 7018/Ali 5451 PCI Audio, version 0.14.6a, 23:57:52 Oct 3 2000
trident: Trident 4DWave DX found at IO
An attempt to use on Alpha UX a 'trident' module on 2.2.18pre15 (and
2.2.17, and 2.2.16 with patches) with a sound card present ends up
with the following lines in 'dmesg':
Trident 4DWave/SiS 7018/Ali 5451 PCI Audio, version 0.14.6a, 23:57:52 Oct 3 2000
trident: Trident 4DWave DX found at IO
I tried to boot recent 2.4.0 kernels (the last one 2.4.0-test9-pre5)
on Ruffian type of Alpha, also known as UX, with a notable lack
of success. So far I had not a single succesful boot. My test
machine ran without any hiccups various 2.2 kernels, patched and
upatched, and before that a long
I tried to boot recent 2.4.0 kernels (the last one 2.4.0-test9-pre5)
on Ruffian type of Alpha, also known as UX, with a notable lack
of success. So far I had not a single succesful boot. My test
machine ran without any hiccups various 2.2 kernels, patched and
upatched, and before that a long
I found by an experiment that an Alpha with a device which provides
its own PCI bridge, and if that device is on a PCI bus 0, will stop
booting right after "Partition check" messages. The only way out is
through a power switch. One can still boot if the device in question
is plugged in a slot
I found by an experiment that an Alpha with a device which provides
its own PCI bridge, and if that device is on a PCI bus 0, will stop
booting right after "Partition check" messages. The only way out is
through a power switch. One can still boot if the device in question
is plugged in a slot
Jamie Lokier wrote:
> World Domination is my hobby too :-)
Now, that is THE T-shirt! What should be added? A flock of penguins
in an attack mode. :-)
--mj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
1 - 100 of 101 matches
Mail list logo
