Reviewed-by: David Riley
On Wed, Oct 21, 2020 at 8:05 AM Hui Su wrote:
>
> before(when i did not compile udelay_test.ko):
> sh@ubuntu:~/workspace/compile/tools/time$ sudo ./udelay_test.sh
> ./udelay_test.sh: line 25: /sys/kernel/debug/udelay_test: Permission denied
> ./udelay_t
Userspace requested command buffer allocations could be too large
to make as a contiguous allocation. Use vmalloc if necessary to
satisfy those allocations.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +-
drivers/gpu/drm/virtio/virtgpu_vq.c| 78
On Sun, Sep 1, 2019 at 10:28 PM Gerd Hoffmann wrote:
>
> On Fri, Aug 30, 2019 at 10:49:25AM -0700, David Riley wrote:
> > Hi Gerd,
> >
> > On Fri, Aug 30, 2019 at 4:16 AM Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > > >
details:
http://lists.openwall.net/linux-kernel/2011/01/12/372
Cc: John Stultz <john.stu...@linaro.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Russell King <rmk+ker...@armlinux.org.uk>
Signed-off-by: David Riley <davidri...@chromium.org>
---
kernel/time/test_udelay.c | 4
details:
http://lists.openwall.net/linux-kernel/2011/01/12/372
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Russell King
Signed-off-by: David Riley
---
kernel/time/test_udelay.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/test_udelay.c b/kernel/time
Cc: Stephen Rothwell
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Linux-Next
> Cc: David Riley
> Signed-off-by: John Stultz
Reviewed-by: David Riley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord..
: Greg KH g...@kroah.com
Cc: Stephen Rothwell s...@canb.auug.org.au
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@elte.hu
Cc: Linux-Next linux-n...@vger.kernel.org
Cc: David Riley davidri...@chromium.org
Signed-off-by: John Stultz john.stu...@linaro.org
Reviewed-by: David Riley
Hi Tuomas,
A bunch of small nit picks from me.
On Wed, Aug 20, 2014 at 2:04 PM, Tuomas Tynkkynen wrote:
> Add shared code to support the Tegra DFLL clocksource in open-loop
> mode. This root clocksource is present on the Tegra124 SoCs. The
> DFLL is the intended primary clock source for the
This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree bindings.
Signed-off-by: David Riley
---
.../devicetree/bindings/gpio/gpio-restart.txt | 54
drivers/power/reset/Kconfig| 8 ++
drivers/power/reset
- Changed priority property from u8 type to standard u32
- Rename input property to open-source
- Made delays configurable from binding
- Removed unneeded BUG_ON
- Used devm_gpiod_get flags parameter to configure initial direction
David Riley (1):
power: Add simple gpio
On Tue, Aug 26, 2014 at 7:40 PM, Guenter Roeck wrote:
> On 08/26/2014 04:45 PM, David Riley wrote:
>>
>> This driver registers a restart handler to set a GPIO line high/low
>> to reset a board based on devicetree bindings.
>>
>> Signed-off-by: David Riley
>>
Hi Olof,
On Tue, Aug 26, 2014 at 7:14 PM, Olof Johansson wrote:
> Hi,
>
>
>
> On Tue, Aug 26, 2014 at 4:45 PM, David Riley wrote:
>> This driver registers a restart handler to set a GPIO line high/low
>> to reset a board based on devicetree bindings.
>&
Hi Sebastian,
Thanks for the feedback.
On Tue, Aug 26, 2014 at 6:43 PM, Sebastian Reichel wrote:
> Hi David,
>
> On Tue, Aug 26, 2014 at 04:45:05PM -0700, David Riley wrote:
>> This driver registers a restart handler to set a GPIO line high/low
>> to reset a board based o
Hi Sebastian,
Thanks for the feedback.
On Tue, Aug 26, 2014 at 6:43 PM, Sebastian Reichel s...@kernel.org wrote:
Hi David,
On Tue, Aug 26, 2014 at 04:45:05PM -0700, David Riley wrote:
This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree
Hi Olof,
On Tue, Aug 26, 2014 at 7:14 PM, Olof Johansson o...@lixom.net wrote:
Hi,
On Tue, Aug 26, 2014 at 4:45 PM, David Riley davidri...@chromium.org wrote:
This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree bindings.
Signed-off
On Tue, Aug 26, 2014 at 7:40 PM, Guenter Roeck li...@roeck-us.net wrote:
On 08/26/2014 04:45 PM, David Riley wrote:
This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree bindings.
Signed-off-by: David Riley davidri...@chromium.org
This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree bindings.
Signed-off-by: David Riley davidri...@chromium.org
---
.../devicetree/bindings/gpio/gpio-restart.txt | 54
drivers/power/reset/Kconfig| 8
- Changed priority property from u8 type to standard u32
- Rename input property to open-source
- Made delays configurable from binding
- Removed unneeded BUG_ON
- Used devm_gpiod_get flags parameter to configure initial direction
David Riley (1):
power: Add simple gpio
Hi Tuomas,
A bunch of small nit picks from me.
On Wed, Aug 20, 2014 at 2:04 PM, Tuomas Tynkkynen ttynkky...@nvidia.com wrote:
Add shared code to support the Tegra DFLL clocksource in open-loop
mode. This root clocksource is present on the Tegra124 SoCs. The
DFLL is the intended primary clock
/patch/4746721/
https://patchwork.kernel.org/patch/4746731/
https://patchwork.kernel.org/patch/4747011/
https://patchwork.kernel.org/patch/4746741/
https://patchwork.kernel.org/patch/4746861/
David Riley (1):
power: Add simple gpio-restart driver
.../devicetree/bindings/gpio/gpio-restart.txt
This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree bindings.
Signed-off-by: David Riley
---
.../devicetree/bindings/gpio/gpio-restart.txt | 48 +++
drivers/power/reset/Kconfig| 8 ++
drivers/power/reset
This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree bindings.
Signed-off-by: David Riley davidri...@chromium.org
---
.../devicetree/bindings/gpio/gpio-restart.txt | 48 +++
drivers/power/reset/Kconfig| 8
/patch/4746721/
https://patchwork.kernel.org/patch/4746731/
https://patchwork.kernel.org/patch/4747011/
https://patchwork.kernel.org/patch/4746741/
https://patchwork.kernel.org/patch/4746861/
David Riley (1):
power: Add simple gpio-restart driver
.../devicetree/bindings/gpio/gpio-restart.txt
tephen Rothwell
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Linux-Next
> Cc: David Riley
> Signed-off-by: John Stultz
Acked-by: David Riley
> ---
> kernel/time/Makefile | 2 +-
> kernel/time/test_udelay.c | 168
> +
: Greg KH g...@kroah.com
Cc: Stephen Rothwell s...@canb.auug.org.au
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@elte.hu
Cc: Linux-Next linux-n...@vger.kernel.org
Cc: David Riley davidri...@chromium.org
Signed-off-by: John Stultz john.stu...@linaro.org
Acked-by: David Riley
- update commit message to indicate what this test targets
- fixed checkpatch whitespace error
- rebased
Changes since v3:
- fixed xtensa compile warning (and other 32-bit platforms which
use the generic do_div)
- renamed and moved config option
David Riley (2):
kernel: time: Add udelay_test
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley
---
tools/time/udelay_test.sh | 66 +++
1 file changed, 66 insertions(+)
create mode
delay instead. This test aims to identify
those configurations where timing is unreliable.
Signed-off-by: David Riley
---
kernel/time/Makefile | 1 +
kernel/time/udelay_test.c | 168 ++
lib/Kconfig.debug | 9 +++
3 files changed, 178
delay instead. This test aims to identify
those configurations where timing is unreliable.
Signed-off-by: David Riley davidri...@chromium.org
---
kernel/time/Makefile | 1 +
kernel/time/udelay_test.c | 168 ++
lib/Kconfig.debug | 9
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley davidri...@chromium.org
---
tools/time/udelay_test.sh | 66 +++
1 file changed, 66
- update commit message to indicate what this test targets
- fixed checkpatch whitespace error
- rebased
Changes since v3:
- fixed xtensa compile warning (and other 32-bit platforms which
use the generic do_div)
- renamed and moved config option
David Riley (2):
kernel: time: Add udelay_test
On Fri, Jun 13, 2014 at 9:06 AM, John Stultz wrote:
> On Thu, Jun 12, 2014 at 1:13 PM, David Riley wrote:
>> Create a module that allows udelay() to be executed to ensure that
>> it is delaying at least as long as requested (with a little bit of
>> error allowed).
On Fri, Jun 13, 2014 at 9:06 AM, John Stultz john.stu...@linaro.org wrote:
On Thu, Jun 12, 2014 at 1:13 PM, David Riley davidri...@chromium.org wrote:
Create a module that allows udelay() to be executed to ensure that
it is delaying at least as long as requested (with a little bit of
error
delay instead. This test aims to identify
those configurations where timing is unreliable.
Signed-off-by: David Riley
---
kernel/time/Kconfig | 7 ++
kernel/time/Makefile | 1 +
kernel/time/udelay_test.c | 170 ++
3 files changed, 178
- update commit message to indicate what this test targets
- fixed checkpatch whitespace error
- rebased
David Riley (2):
kernel: time: Add udelay_test module to validate udelay
tools: add script to test udelay
kernel/time/Kconfig | 7 ++
kernel/time/Makefile | 1 +
kernel/time
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley
---
tools/time/udelay_test.sh | 66 +++
1 file changed, 66 insertions(+)
create mode
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley davidri...@chromium.org
---
tools/time/udelay_test.sh | 66 +++
1 file changed, 66
- update commit message to indicate what this test targets
- fixed checkpatch whitespace error
- rebased
David Riley (2):
kernel: time: Add udelay_test module to validate udelay
tools: add script to test udelay
kernel/time/Kconfig | 7 ++
kernel/time/Makefile | 1 +
kernel/time
delay instead. This test aims to identify
those configurations where timing is unreliable.
Signed-off-by: David Riley davidri...@chromium.org
---
kernel/time/Kconfig | 7 ++
kernel/time/Makefile | 1 +
kernel/time/udelay_test.c | 170
Hi,
I was wondering if there were any comments to this patch or if it was
picked up somewhere?
Thanks,
Dave
On Wed, May 14, 2014 at 3:30 PM, David Riley wrote:
> This change adds a module and a script that makes use of it to
> validate that udelay delays for at least as long as req
Hi,
I was wondering if there were any comments to this patch or if it was
picked up somewhere?
Thanks,
Dave
On Wed, May 14, 2014 at 3:30 PM, David Riley davidri...@chromium.org wrote:
This change adds a module and a script that makes use of it to
validate that udelay delays for at least
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley
---
tools/time/udelay_test.sh | 66 +
1 file changed, 66 insertions(+)
create mode
This change adds a module and a script that makes use of it to
validate that udelay delays for at least as long as requested
(as compared to ktime).
Changes since v1:
- allow udelay() to be 0.5% faster than requested as per feedback
David Riley (2):
kernel: time: Add udelay_test module
Create a module that allows udelay() to be executed to ensure that
it is delaying at least as long as requested (with a little bit of
error allowed).
Signed-off-by: David Riley
Reviewed-by: Doug Anderson
---
kernel/time/Kconfig |7 ++
kernel/time/Makefile |1 +
kernel/time
Create a module that allows udelay() to be executed to ensure that
it is delaying at least as long as requested (with a little bit of
error allowed).
Signed-off-by: David Riley davidri...@chromium.org
Reviewed-by: Doug Anderson diand...@chromium.org
---
kernel/time/Kconfig |7
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley davidri...@chromium.org
---
tools/time/udelay_test.sh | 66 +
1 file changed, 66
This change adds a module and a script that makes use of it to
validate that udelay delays for at least as long as requested
(as compared to ktime).
Changes since v1:
- allow udelay() to be 0.5% faster than requested as per feedback
David Riley (2):
kernel: time: Add udelay_test module
On Tue, May 6, 2014 at 9:19 PM, Doug Anderson wrote:
> John,
>
> On Tue, May 6, 2014 at 5:25 PM, John Stultz wrote:
>> On 05/06/2014 05:12 PM, David Riley wrote:
>>> This change adds a module and a script that makes use of it to
>>> validate that udelay delays
On Tue, May 6, 2014 at 9:19 PM, Doug Anderson diand...@chromium.org wrote:
John,
On Tue, May 6, 2014 at 5:25 PM, John Stultz john.stu...@linaro.org wrote:
On 05/06/2014 05:12 PM, David Riley wrote:
This change adds a module and a script that makes use of it to
validate that udelay delays
This change adds a module and a script that makes use of it to
validate that udelay delays for at least as long as requested
(as compared to ktime).
David Riley (2):
kernel: time: Add udelay_test module to validate udelay
tools: add script to test udelay
kernel/time/Kconfig |7
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley
---
tools/time/udelay_test.sh | 66 +
1 file changed, 66 insertions(+)
create mode
Create a module that allows udelay() to be executed to ensure that
it is delaying at least as long as requested.
Signed-off-by: David Riley
Reviewed-on: https://chromium-review.googlesource.com/194223
Reviewed-by: Doug Anderson
---
kernel/time/Kconfig |7 ++
kernel/time/Makefile
Create a module that allows udelay() to be executed to ensure that
it is delaying at least as long as requested.
Signed-off-by: David Riley davidri...@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/194223
Reviewed-by: Doug Anderson diand...@chromium.org
---
kernel/time
This change adds a module and a script that makes use of it to
validate that udelay delays for at least as long as requested
(as compared to ktime).
David Riley (2):
kernel: time: Add udelay_test module to validate udelay
tools: add script to test udelay
kernel/time/Kconfig |7
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley davidri...@chromium.org
---
tools/time/udelay_test.sh | 66 +
1 file changed, 66
The documentation for the es1371 driver doesn't mention how to
activate/specify the joystick port's base address (I had to look in the
code). This patch fixes it. The same probably applies to the es1370 as
well as other cards, but lacking said cards, I couldn't say for sure.
You may wish to
The documentation for the es1371 driver doesn't mention how to
activate/specify the joystick port's base address (I had to look in the
code). This patch fixes it. The same probably applies to the es1370 as
well as other cards, but lacking said cards, I couldn't say for sure.
You may wish to
Linus Torvalds wrote:
Uhm, yeah... I don't know who wrote this, but it came from Washington
state and was written with MS Outlook... Something tells me that this
April Fool's joke wasn't Linus'. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Linus Torvalds wrote:
Uhm, yeah... I don't know who wrote this, but it came from Washington
state and was written with MS Outlook... Something tells me that this
April Fool's joke wasn't Linus'. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Alan Cox wrote:
> 2.4.2-ac12
> o Update VIA IDE driver to 3.21 (Vojtech Pavlik)
> |No UDMA66 on 82c686
Um... Does that include 686a? 82c686a is supposed to handle UDMA66...
Or is it a corruption issue again? UDMA66 seems to work fine on
mine... No corruptions
Alan Cox wrote:
2.4.2-ac12
o Update VIA IDE driver to 3.21 (Vojtech Pavlik)
|No UDMA66 on 82c686
Um... Does that include 686a? 82c686a is supposed to handle UDMA66...
Or is it a corruption issue again? UDMA66 seems to work fine on
mine... No corruptions yet.
This is in kernel 2.4.2. I don't really know how long this has been
going on, but I would guess that it's been like this since I got my
board (the performance has been the same throughout).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
I knew my performance hit had to be coming from somewhere...
I'm using an MSI K7T Pro mtherboard (KT133 chipset) and a Voodoo3 2000.
I can't seem to set bus mastering on the AGP card at all. This does not
work:
setpci -s 01:00.0 4.w=0007 (setpci -s 01:00.0 4.w gives me 0003)
Nor does:
I knew my performance hit had to be coming from somewhere...
I'm using an MSI K7T Pro mtherboard (KT133 chipset) and a Voodoo3 2000.
I can't seem to set bus mastering on the AGP card at all. This does not
work:
setpci -s 01:00.0 4.w=0007 (setpci -s 01:00.0 4.w gives me 0003)
Nor does:
This is in kernel 2.4.2. I don't really know how long this has been
going on, but I would guess that it's been like this since I got my
board (the performance has been the same throughout).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Mark Hahn wrote:
>
> >>From what I gather this chipset on 2.4.x is only stable if you cripple just about
>everything that makes
> > it worth having (udma, 2nd ide channel etc etc) ?does it even work when all
>that's done now or is
> > it fully functional?
>
> it seems to be fully
Mark Hahn wrote:
From what I gather this chipset on 2.4.x is only stable if you cripple just about
everything that makes
it worth having (udma, 2nd ide channel etc etc) ?does it even work when all
that's done now or is
it fully functional?
it seems to be fully functional for
Chris Wedgwood wrote:
>
> On Mon, Jan 29, 2001 at 11:17:58PM -0800, Linus Torvalds wrote:
>
> You have to realize that stability takes precedence over
> EVERYTHING.
>
> Are you sure his desciption describes only disk-slow down? Seems to
> me something else is going on... why would
Chris Wedgwood wrote:
On Mon, Jan 29, 2001 at 11:17:58PM -0800, Linus Torvalds wrote:
You have to realize that stability takes precedence over
EVERYTHING.
Are you sure his desciption describes only disk-slow down? Seems to
me something else is going on... why would speaker
Sorry if this is a redundant post, but I didn't see any related posts
(at least from the subject lines)...
Kernel 2.4.1-pre11 and pre12 are both massively slower than 2.4.0 on the
same machine, compiled with the same options. The machine is a Athlon
900 on a KT133 chipset. The slowdown is
Sorry if this is a redundant post, but I didn't see any related posts
(at least from the subject lines)...
Kernel 2.4.1-pre11 and pre12 are both massively slower than 2.4.0 on the
same machine, compiled with the same options. The machine is a Athlon
900 on a KT133 chipset. The slowdown is
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> A patch for the via82cxxx_audio sound driver against 2.4.1-pre8.
> It includes:
>
> 1. Support for variable fragment size and variable fragment number
> 2. Fixes for the SPEED, STEREO, CHANNELS, FMT ioctls when in read & write
> mode
> 2.1 Mmaped sound is
[EMAIL PROTECTED] wrote:
Hi,
A patch for the via82cxxx_audio sound driver against 2.4.1-pre8.
It includes:
1. Support for variable fragment size and variable fragment number
2. Fixes for the SPEED, STEREO, CHANNELS, FMT ioctls when in read write
mode
2.1 Mmaped sound is now fully
Marvin Stodolsky wrote:
>
> To Maintainer:
> PCI SUBSYSTEM
> P: Martin Mares
> M: [EMAIL PROTECTED]
> L: [EMAIL PROTECTED]
> S: Supported
>
> This alert should probably be forwarded to Others, but appropriate
> subTask persons in the kernel-source Maintainers list were not
Marvin Stodolsky wrote:
To Maintainer:
PCI SUBSYSTEM
P: Martin Mares
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Supported
This alert should probably be forwarded to Others, but appropriate
subTask persons in the kernel-source Maintainers list were not obvious.
Alexander Viro wrote:
>
> Actually, I suspect that quite a few of us had done that since long -
> IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I
> remember what exactly it was - ISTR that it was restore(8) built with
> 1.3. headers and playing funny games on
Did I miss a post from Linus on the list, or is there no posted
changelog for test13-pre1? Nothing's posted at kernel.org yet, either.
--
"Windows for Dummies? Isn't that redundant?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Did I miss a post from Linus on the list, or is there no posted
changelog for test13-pre1? Nothing's posted at kernel.org yet, either.
--
"Windows for Dummies? Isn't that redundant?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Alexander Viro wrote:
Actually, I suspect that quite a few of us had done that since long -
IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I
remember what exactly it was - ISTR that it was restore(8) built with
1.3.something headers and playing funny games
Martin Macok wrote:
>
> Hi,
> after 1-3 hours with -test12 system hangs up with
> - no response from mouse
> - no response from keyboard (no sysrq, only sysrq+'b' works ...)
> - no response from network (ICMP, TCP)
> - nothing on console, nothing in logs (ie. nothing interesting or relevant
Paul Jakma wrote:
>
> hi,
>
> i think somethings gone wrong with via82cxxx_audio. Playing anything
> through it seems to cause massive latency in apps like xmms, esd,
> asmixer, etc.. anything to do with playing or mixer levels suddenly
> takes a minute or more to respond.
>
> It didn't always
Paul Jakma wrote:
hi,
i think somethings gone wrong with via82cxxx_audio. Playing anything
through it seems to cause massive latency in apps like xmms, esd,
asmixer, etc.. anything to do with playing or mixer levels suddenly
takes a minute or more to respond.
It didn't always do this,
Martin Macok wrote:
Hi,
after 1-3 hours with -test12 system hangs up with
- no response from mouse
- no response from keyboard (no sysrq, only sysrq+'b' works ...)
- no response from network (ICMP, TCP)
- nothing on console, nothing in logs (ie. nothing interesting or relevant
to
Bryan Whitehead wrote:
>
> Is there a way I can disble a part of the kernel that is compiled into the
> kernel? For example I'd like to pass this to lilo: "usb=disable" and then
> the usb code is not loaded even though USB has been built into the kernel.
>
> Is such a feature stupid? Or has
Bryan Whitehead wrote:
Is there a way I can disble a part of the kernel that is compiled into the
kernel? For example I'd like to pass this to lilo: "usb=disable" and then
the usb code is not loaded even though USB has been built into the kernel.
Is such a feature stupid? Or has this
Oops,
I included the wrong diff. Perhaps I should check them better next
time. Here's one that should work.
elf.h.diff
In asm-ppc/elf.h, is not included. This breaks
compilations of anything that compiles it (e.g. binutils) because the
vector registers for Altivec aren't defined elsewhere. Included is a
quick diff. I didn't know which PPC maintainer to send this to, so I
posted it to the linuxppc-dev list.
In asm-ppc/elf.h, asm/types.h is not included. This breaks
compilations of anything that compiles it (e.g. binutils) because the
vector registers for Altivec aren't defined elsewhere. Included is a
quick diff. I didn't know which PPC maintainer to send this to, so I
posted it to the
Oops,
I included the wrong diff. Perhaps I should check them better next
time. Here's one that should work.
elf.h.diff
Jeff Epler wrote:
> Well, a copy of that document *is* the first hit for a google search on
> 'linux signal 11 faq'
> http://www.google.com/search?q=linux+signal+11+faq
>
> In other words, someone who does the slightest bit of research will
> find the answer.
Perhaps, but if a new user
Jeff Epler wrote:
Well, a copy of that document *is* the first hit for a google search on
'linux signal 11 faq'
http://www.google.com/search?q=linux+signal+11+faq
In other words, someone who does the slightest bit of research will
find the answer.
Perhaps, but if a new user starts
Richard Torkar wrote:
>
> Well David, there is such a "manual".
>
> http://ftp.sunet.se/LDP/FAQ/faqs/GCC-SIG11-FAQ
Yes. And if you ask the average new Linux user if they've read it, I
doubt you'll get a "yes". My question boils down to this, and this I
suppose is a personal/informational
Jeff Epler wrote:
>
> On Tue, Nov 21, 2000 at 04:08:26PM -0500, David Riley wrote:
> > Windoze is not the only OS to handle bad hardware better than Linux. On
> > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept
> > causing random bus-type errors i
David Lang wrote:
>
> David, usually when it turns out that Linux finds hardware problems the
> underlying cause is that linux makes more effective use of the component,
> and as such something that was marginal under windows fails under linux as
> the correct timing is used.
This is true.
Horst von Brand wrote:
>
> So what? My former machine ran fine with Win95/WinNT. Linux wouldn't even
> end booting the kernel. Reason: P/100 was running at 120Mhz. Fixed that, no
> trouble for years. Not the only case of WinXX running (apparently?) fine
> on broken/misconfigured hardware I've
Horst von Brand wrote:
So what? My former machine ran fine with Win95/WinNT. Linux wouldn't even
end booting the kernel. Reason: P/100 was running at 120Mhz. Fixed that, no
trouble for years. Not the only case of WinXX running (apparently?) fine
on broken/misconfigured hardware I've seen,
David Lang wrote:
David, usually when it turns out that Linux finds hardware problems the
underlying cause is that linux makes more effective use of the component,
and as such something that was marginal under windows fails under linux as
the correct timing is used.
This is true. What I
Jeff Epler wrote:
On Tue, Nov 21, 2000 at 04:08:26PM -0500, David Riley wrote:
Windoze is not the only OS to handle bad hardware better than Linux. On
my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept
causing random bus-type errors in Linux. Same as when I
"Stephen Gutknecht (linux-kernel)" wrote:
>
> Thanks for the prior help on getting the kernel to compile; real newbie
> mistake of not finding the right options in the "make menuconfig" screens.
>
> I can now compile 2.4.0-test, but it hangs on the first line of loading.
>
> -- I have tried
"Stephen Gutknecht (linux-kernel)" wrote:
Thanks for the prior help on getting the kernel to compile; real newbie
mistake of not finding the right options in the "make menuconfig" screens.
I can now compile 2.4.0-test, but it hangs on the first line of loading.
-- I have tried
1 - 100 of 116 matches
Mail list logo
