* Re: [BK fbdev] Yet again more fbdev updates.
From: Linus Torvalds @ 2002-12-14 1:11 UTC (permalink / raw)
To: James Simmons
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.33.0212131745130.1882-100000@maxwell.earthlink.net>
On Fri, 13 Dec 2002, James Simmons wrote:
>
> If it happens only when you press a key which is always true:
>
> 1) Its the same place on the screen or a different place every time?
I think it's at the last line of the screen every time.
> 3) Always the last column?
Nope, I don't think so.
> If you don't mind me asking what is model of your laptop to see if
> someone else is having the same exact problem.
This is a HP ze5155 (big, heavy and horrible, but cheap). But I seriously
doubt that is the real issue: I suspect that the reason I see it on that
machine is (a) I was travelling the last three days and that was the only
machine I had and (b) because X is flaky at starting up on it, I wasn't in
X all the time like I normally am.
Linus
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [BK][PATCH] ReiserFS CPU and memory bandwidth efficient large writes
From: Hans Reiser @ 2002-12-14 1:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <3DFA53DA.DE6788C1@digeo.com>
Andrew, thanks much for these helpful suggestions and detailed review.
Oleg will reply in detail on Monday.
Hans
^ permalink raw reply
* Re: [BK fbdev] Yet again more fbdev updates.
From: Linus Torvalds @ 2002-12-14 1:11 UTC (permalink / raw)
To: James Simmons
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.33.0212131745130.1882-100000@maxwell.earthlink.net>
On Fri, 13 Dec 2002, James Simmons wrote:
>
> If it happens only when you press a key which is always true:
>
> 1) Its the same place on the screen or a different place every time?
I think it's at the last line of the screen every time.
> 3) Always the last column?
Nope, I don't think so.
> If you don't mind me asking what is model of your laptop to see if
> someone else is having the same exact problem.
This is a HP ze5155 (big, heavy and horrible, but cheap). But I seriously
doubt that is the real issue: I suspect that the reason I see it on that
machine is (a) I was travelling the last three days and that was the only
machine I had and (b) because X is flaky at starting up on it, I wasn't in
X all the time like I normally am.
Linus
^ permalink raw reply
* Re: [BK fbdev] Yet again more fbdev updates.
From: James Simmons @ 2002-12-14 1:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0212131611490.6750-100000@home.transmeta.com>
> This is UP, and not preemptible. And the backtrace may be corrupt, because
> when the page fault happens, it will actually page fault _again_ as part
> of trying to print out the oops, so the whole thing scrolls largely off
> the screen..
Thats right. If the low level console driver is broken it will call
printk which could be using the broken driver :-(
> I only see this on one of my laptops, and even there it seems to be
> timing-dependent or something (I think it only happens when I press a key,
> and because the backtrace isn't trustworthy ..)
If it happens only when you press a key which is always true:
1) Its the same place on the screen or a different place every time?
2) Always the last line of the screen?
3) Always the last column?
If you don't mind me asking what is model of your laptop to see if someone
else is having the same exact problem.
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Maciej W. Rozycki @ 2002-12-14 0:55 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips
In-Reply-To: <20021213150853.F22731@mvista.com>
On Fri, 13 Dec 2002, Jun Sun wrote:
> This patch adds support for those sorry boards which only have
> option 2) available.
>
> While I am here, I also promoted do_IRQ() declaration to a
> header file, as it is needed by all C-level interrupt dispatching
> code.
>
> Any feedbacks?
Yep -- a few random thoughts.
> +asmlinkage void dispatch_i8259_irq(struct pt_regs *regs)
> +{
> + int isr, irq=-1;
> +
> + isr = ~(int)inb(0x20) | cached_21;
OCW3 defaults to IRR in our setup (as it does for the chip itself after
writing ICWs) -- you need to select ISR explicitly before reading and
reset it afterwards to avoid surprises. Unless we change the default for
MIPS, which seems feasible -- we don't have to handle i386 oddities like
I/O APICs and weird chipset bugs. And we avoid the need to grab a
spinlock here. Alpha went this path.
> + if (isr != -1)
> + irq = ffz (isr);
> + if (irq == 2) {
> + isr = ~(int)inb(0xa0) | cached_A1;
> + if (isr != -1)
> + irq = 8 + ffz(isr);
> + }
> + if (irq == -1) {
> + printk("We got a spurious i8259 interrupt\n");
The wording is odd -- how about following the one from
arch/i386/kernel/i8259.c?
> + atomic_inc(&irq_err_count);
> + } else {
> + do_IRQ(irq,regs);
And how about using an offset passed from a user? We're not on a PC --
i8259 IRQs do not have to start from 0. E.g. I find cleaner allocating
CPU IRQs first if handled.
> --- ./include/asm-mips64/irq.h.orig Fri Dec 13 10:51:25 2002
> +++ ./include/asm-mips64/irq.h Fri Dec 13 14:50:46 2002
[...]
> +extern asmlinkage unsigned int do_IRQ(int irq, struct pt_regs *regs);
Hmm, <asm/hw_irq.h> might be a better alternative. I have no strong
preference, though. Both get included by <linux/irq.h> so there's no
difference for a user.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Mailing list fixed.
From: James Simmons @ 2002-12-14 1:45 UTC (permalink / raw)
To: Linux Fbdev development list
Hi folks!!
I made the mailing list public again to make everyone happy :-)
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsimmons@users.sf.net] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: new Debian packages
From: Brian May @ 2002-12-14 0:53 UTC (permalink / raw)
To: Tom; +Cc: selinux
In-Reply-To: <20021214004206.D22479@lemuria.org>
On Sat, Dec 14, 2002 at 12:42:07AM +0100, Tom wrote:
> I'll be testing this next week. Any new kernels from Brian that I could
> give a shakedown while I'm at it? (I've hosed my test machine again.
> Must remember to be more careful. Will probably write a new chapter
> into my "things not to do with SELinux" paper. :) )
The latest patch I have, at the usual place, is for the 2.4.19
kernel.
It has at least one know security bug fixed in the kernel, plus lots
of patches I need from time to time (eg. EVMS, ACL, SE-Linux, FreeS/WAN,
DOV).
I am not sure if there are version of these patches that will work
with 2.4.20 yet, that is something I need to investigate (DOV at least
is suppost to have been integrated into the kernel by now).
Also I haven't yet been able to get EVMS working properly (the kernel
fails to "discover" EVMS volumes), but that may be my fault, and is
off-topic for this list anyway.
--
Brian May <bam@snoopy.apana.org.au>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [BK fbdev] Yet again more fbdev updates.
From: James Simmons @ 2002-12-14 1:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0212131611490.6750-100000@home.transmeta.com>
> This is UP, and not preemptible. And the backtrace may be corrupt, because
> when the page fault happens, it will actually page fault _again_ as part
> of trying to print out the oops, so the whole thing scrolls largely off
> the screen..
Thats right. If the low level console driver is broken it will call
printk which could be using the broken driver :-(
> I only see this on one of my laptops, and even there it seems to be
> timing-dependent or something (I think it only happens when I press a key,
> and because the backtrace isn't trustworthy ..)
If it happens only when you press a key which is always true:
1) Its the same place on the screen or a different place every time?
2) Always the last line of the screen?
3) Always the last column?
If you don't mind me asking what is model of your laptop to see if someone
else is having the same exact problem.
^ permalink raw reply
* test
From: James Simmons @ 2002-12-14 1:41 UTC (permalink / raw)
To: Linux Fbdev development list
test
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsimmons@users.sf.net] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: GrandMasterLee @ 2002-12-14 0:55 UTC (permalink / raw)
To: Mike Hayward; +Cc: wli, linux-kernel
In-Reply-To: <200212131649.gBDGnSS04425@flux.loup.net>
On Fri, 2002-12-13 at 10:49, Mike Hayward wrote:
> Hi Bill,
>
> > On Mon, Dec 09, 2002 at 01:30:28AM -0700, Mike Hayward wrote:
> > > Any ideas? Not sure I want to upgrade to the P7 architecture if this
> > > is right, since for me system calls are probably more important than
> > > raw cpu computational power.
> >
> > This is the same for me. I'm extremely uninterested in the P-IV for my
> > own use because of this.
>
> I've also noticed that algorithms like the recursive one I run which
> simulates solving the Tower of Hanoi problem are most likely very hard
> to do branch prediction on. Both the code and data no doubt fit
> entirely in the L2 cache. The AMD processor below is a much lower
> cost and significantly lower clock rate (and on a machine with only a
> 100Mhz Memory bus) than the Xeon, yet dramatically outperforms it with
> the same executable, compiled with gcc -march=i686 -O3. Maybe with a
> better Pentium 4 optimizing compiler the P4 and Xeon could improve a
> few percent, but I doubt it'll ever see the AMD numbers.
What GCC were you using? I'd use 3.2, or 3.2.1 myself with
-march=pentium4 and -mcpu=pentium4 to see if there *is* any difference
there. On my quad P4 Xeon 1.6Ghz with 1M L3 cache, I can compile a
kernel in about 35 seconds. Mind you that's my own config, not
*everything*. On a dual athlon MP at 1.8 Ghz, I get about 5 mins or so.
Both are running with make -jx where X is the saturation value.
> Recursion Test--Tower of Hanoi
>
> Uni AMD XP 1800 2.4.18 kernel 46751.6 lps (10 secs, 6 samples)
> Dual Pentium 4 Xeon 2.4Ghz 2.4.19 kernel 33661.9 lps (10 secs, 6 samples)
>
> - Mike
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
GrandMasterLee <masterlee@digitalroadkill.net>
^ permalink raw reply
* Help Understanding what causes kernel stack overflow.
From: GrandMasterLee @ 2002-12-14 0:51 UTC (permalink / raw)
To: linux-kernel
Kernel: 2.4.19-aa1
FS are all XFS. Kernel has no modules, except Qlogic drivers(6.01-fo)
I've been dealing with some pretty regular, albeit severe stack overflow
issues which crashes one of my two DB servers from time to time. We
currently are on a schedule to reboot them every week to prevent the
systems from hanging/crashing/etc.
We recently were able to make some correlation to backup times and the
potential stack overflow detection messages. I've got a traces from our
kernel log and messages files. I was curious if there were currently any
tools to examine the stack call traces in detail.
I tried using ksymoops, but it really didn't give me any more than I
already had in messages. Any advice on the *best* way to proceed
debugging what is causing stack overflows given I have the call traces?
Currently, I've dumped all the objects from the running kernel(objdump
-Dr vmlinux) and will search for the "sub" lines which correspond to
%esp. I'll then take the functions which are listed in my call trace,
and add up the total each function uses to see if that is the right
path, then to try an reproduce it, given the call traces I have.
Any help on doing this would be wonderful.
--
GrandMasterLee <masterlee@digitalroadkill.net>
^ permalink raw reply
* test
From: James Simmons @ 2002-12-14 1:33 UTC (permalink / raw)
To: Linux Fbdev development list
test
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsimmons@users.sf.net] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [RESEND] [OOPS & TRIVIAL PATCH 2.4.20] NULL pointer dereference in ide.c, ide_revalidate_disk()
From: Marcelo Tosatti @ 2002-12-13 21:49 UTC (permalink / raw)
To: Paul.Clements; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.10.10212111331020.438-200000@clements.sc.steeleye.com>
On Wed, 11 Dec 2002, Paul Clements wrote:
> Problem still exists in 2.4.20. Please apply if this has not been fixed in some other way.
Paul,
Patch applied.
Thanks.
^ permalink raw reply
* premature closing of bugs in bugzilla.
From: Dave Jones @ 2002-12-14 0:45 UTC (permalink / raw)
To: Linux Kernel
Folks,
Just because there's a resolution to a problem in bugzilla does
not mean you should close the bug you reported. Wait until the
fix is accepted in Linus' tree before doing this, otherwise we
risk people forgetting to push bits.
http://bugzilla.kernel.org/show_bug.cgi?id=162
http://bugzilla.kernel.org/show_bug.cgi?id=163
Are two that I reopened, there may be others, I've
not yet looked..
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [BK fbdev] Yet again more fbdev updates.
From: James Simmons @ 2002-12-14 0:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0212131347240.10159-100000@home.transmeta.com>
> James,
> the fbcon update seems to have broken the plain VGA console. I get a page
> fault at vgacon_scroll+0x144, the call sequence seems to be:
>
> vt_console_print+0x203
> set_cursor+0x78
> vgacon_cursor+x0xb5
> scrup+0x122
> vgacon_scroll+0x144
>
> I don't know what triggers it, since it seems to happen pretty randomly.
Strange. I avoided touching that driver as much as possible. The other
strange error I have seen is vesa mode 791 for some reason stopped woking
on some boards. I just did a diff between 2.5.49 vgacon.c and the current
vgacon.c. The result is
--- /usr/src/linux-2.5.49/drivers/video/vgacon.c Fri Sep 13 14:17:14 2002
+++ vgacon.c Fri Dec 13 15:22:02 2002
@@ -41,7 +41,6 @@
#include <linux/kernel.h>
#include <linux/tty.h>
#include <linux/console.h>
-#include <linux/console_struct.h>
#include <linux/string.h>
#include <linux/kd.h>
#include <linux/slab.h>
@@ -180,6 +179,13 @@
#endif
}
+ /* VGA16 modes are not handled by VGACON */
+ if ((ORIG_VIDEO_MODE == 0x0D) || /* 320x200/4 */
+ (ORIG_VIDEO_MODE == 0x0E) || /* 640x200/4 */
+ (ORIG_VIDEO_MODE == 0x10) || /* 640x350/4 */
+ (ORIG_VIDEO_MODE == 0x12) || /* 640x480/4 */
+ (ORIG_VIDEO_MODE == 0x6A)) /* 800x600/4, 0x6A is very common */
+ goto no_vga;
vga_video_num_lines = ORIG_VIDEO_LINES;
vga_video_num_columns = ORIG_VIDEO_COLS;
@@ -838,8 +844,8 @@
static int
vgacon_adjust_height(unsigned fontheight)
{
- int rows, maxscan;
unsigned char ovr, vde, fsr;
+ int rows, maxscan, i;
if (fontheight == vga_video_font_height)
return 0;
@@ -881,7 +887,12 @@
outb_p( vde, vga_video_port_val );
spin_unlock_irq(&vga_lock);
- vc_resize_all(rows, 0); /* Adjust console size */
+ for (i = 0; i < MAX_NR_CONSOLES; i++) {
+ struct vc_data *c = vc_cons[i].d;
+
+ if (c && c->vc_sw == &vga_con)
+ vc_resize(c->vc_num, 0, rows); /* Adjust console size */
+ }
return 0;
}
Now the first chuck of code was from a vga16fb patch. Originally you
could set a vga graphical mode that was standard but not apart of the VESA
number range (100+) and vgacon would still start. This prevented it.
To the people having trouble setting VESA fb mode 791 remove this code and
tell me if your problem goes away.
The second possible source is in vga_adjust_height. This is called when
you change your font set from userland. I attempted to change my font and
didn't have a problem.
The err you are talking about that is having issues in vgacon_scroll is
c->vc_origin = vga_vram_end - c->vc_screenbuf_size;
Which is when dir equals SM_DOWN and the old origin minus the amount we
scroll is less than A000 (vga_vram_base). Its just strange. I'm going to
stress test vgacon to see what is going on.
^ permalink raw reply
* DMA question for ppc440 PCI board
From: Khai Trinh @ 2002-12-14 0:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi folks,
Does anyone out there work on 440 based PCI board?
I have a DMA problem with the 440 DMA controller. In
our application, the 440 based PCI board is living in
a Solaris host platform. Our PCI board is running with
linux version 2.4.17. So, there are Host software,
driver and embedded linux software, driver, etc...We
want to move data in and out between the Host and the
board. We have defined a messaging system to allow
host software to send messages to the embedded
software. When it comes to time to do DMA, the host
sends a DMA request message containing the PCI bus
address and size of the DMA transfer to the embedded
software.
When the embedded software starts programming the DMA
controller, the 440 requires that the PCI bus address
be mapped to the 440 PLB local bus address. There are
3 sets of POM registers on the 440 supposed to allow
us to remap the PCI bus address into PLB local
address. I did that. But when I started programming
the DMA src register with the PCI mapped PLB address,
and the dst register with the locally allocated
buffer, and enable DMA, no DMA is taken place? What am
I missing? Please advice...
I can even tried to use ioremap64() and pass it with
the mapped LPB address to get kernel virtual address.
The kernel address looks good (ie: c0228000). The one
big problem is that the moment I dereferenced the
virtual pointer using readl, the kernel panic...
That suggested to me that somehow I wasn't able to
perform the map correctly.
I would be appreciated if anyone out there can give me
advice on this problem I have.
Thanks,
--Khai
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH] AGP support VIA VT8633
From: Marcelo Tosatti @ 2002-12-13 21:24 UTC (permalink / raw)
To: Nathaniel Russell; +Cc: linux-kernel, alan
In-Reply-To: <Pine.LNX.4.44.0212110016470.2208-200000@reddog.example.net>
Applied, thanks.
On Wed, 11 Dec 2002, Nathaniel Russell wrote:
> This patch adds support for the Via VT8633 AGP Bridge. Also this patch has
> been tested with a variety of GL apps including the GL ScreenSavers. The
> patch includes the via_generic_setup routines and Device ID's.
> Please Apply against current 2.4.x Kernel
> Nathaniel
> CC Me as I'm not subscribed to the list
> reddog83@chartermi.net
>
^ permalink raw reply
* Re: [BK fbdev] Yet again more fbdev updates.
From: Linus Torvalds @ 2002-12-14 0:14 UTC (permalink / raw)
To: James Simmons
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0212132355040.19622-100000@phoenix.infradead.org>
On Sat, 14 Dec 2002, James Simmons wrote:
>
> Calling scrup is out of place. It is only called by lf() and csi_M() in
> the vt.c. lf() is used in vt_console_print but it is called before
> set_cursor(). Also vgacon_cursor doesn't call vgacon_scroll. It can call
> vgacon_scrolldelta. Now scrup does call vgacon_scroll. It looks like The
> code jumped from the middle of vt_console_print to scrup. Do you get the
> same error all the time? Also do you have Preemptible Kernel turned on?
This is UP, and not preemptible. And the backtrace may be corrupt, because
when the page fault happens, it will actually page fault _again_ as part
of trying to print out the oops, so the whole thing scrolls largely off
the screen..
I only see this on one of my laptops, and even there it seems to be
timing-dependent or something (I think it only happens when I press a key,
and because the backtrace isn't trustworthy ..)
Linus
^ permalink raw reply
* Re: pci-skeleton duplex check
From: Michael Richardson @ 2002-12-14 0:19 UTC (permalink / raw)
To: netdev, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212121539110.10674-100000@beohost.scyld.com>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Donald" == Donald Becker <becker@scyld.com> writes:
Donald> The drivers in the kernel are now heavily modified and have significantly
Donald> diverged from my version. Sure, you are fine with having someone else
Donald> do the difficult and unrewarding debugging and maintainence work, while
Donald> you work on just the latest cool hardware, change the interfaces and are
Donald> concerned only with the current kernel version.
I agree strongly with Donald.
Interfaces should NEVER change in patch level versions.
Just *DO NOT DO IT*.
Go wild in odd-numbered.. get the interfaces right there.
But leave them alone afterward.
This is a fundamental tenant of being professional. Otherwise, the kernel
people are the biggest reason I've ever seen for using *BSD.
Microsoft is not the real enemy. Gratuitous change is.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPfp5IIqHRg3pndX9AQHW7gP9FC0BgskaVBb9HNjKUp8DhR5bJK+YTVa7
YeVGZFRxuFi2O9oDiMuUvYq++y+8PR4LXpJZuNoShA36wqV38QS8pBFhqFt/JrEb
xHNozohQ/7IyncJsG0UkBTfhqIbxbfsd19DUx0ehcqNAh7N3c95qeEEHODTs2DKy
jqtgSrXvOBY=
=JsKT
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: 2.5.5[01]]: Xircom Cardbus broken (PCI resource collisions)
From: Zwane Mwaikambo @ 2002-12-14 0:18 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Dave Jones, Petr Konecny, linux-kernel
In-Reply-To: <200212131846.gBDIk527008838@turing-police.cc.vt.edu>
On Fri, 13 Dec 2002 Valdis.Kletnieks@vt.edu wrote:
> On Fri, 13 Dec 2002 17:36:56 GMT, Dave Jones said:
>
> > It's my understanding that pci_enable_device() *must* be called
> > before we fiddle with dev->resource, dev->irq and the like.
>
> OK.. it looks like the problem only hits if it's a PCMCIA card *with an
> onboard ROM*.
Hmm i just saw this thread, which card is the non working one?;
The computer is still running 2.5.50
02:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: CNet Technology Inc: Unknown device 401a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (5000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 1c00 [size=128]
Region 1: Memory at 10800000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at 10400000 [size=256K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
# PCMCIA/CardBus support
CONFIG_PCMCIA=y
CONFIG_PCMCIA_XIRCOM=y
# CONFIG_PCMCIA_XIRTULIP is not set
# PCMCIA network device support
CONFIG_NET_PCMCIA=y
# CONFIG_PCMCIA_XIRC2PS is not set
--
function.linuxpower.ca
^ permalink raw reply
* Not able to compile modutils-2.4.21-7.src.rpm
From: Paolo Ciarrocchi @ 2002-12-14 0:09 UTC (permalink / raw)
To: adam, rusty; +Cc: linux-kernel
Hi Rusty and Adam,
I send you again this bug report.
[root@frodo module-init-tools-0.9.3]# rpm --rebuild /mnt/nt/linux/kernel/modules/modutils-2.4.21-7.src.rpm
gcc -O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586 -ffast-math -fno-strength-reduce -o modinfo modinfo.o ../obj/libobj.a ../util/libutil.a
gcc -static -O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586 -ffast-math -fno-strength-reduce -o insmod.static insmod.o rmmod.o modprobe.o lsmod.o ksyms.o kallsyms.o ../obj/libobj.a ../util/libutil.a
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make[1]: *** [insmod.static] Error 1
make[1]: Leaving directory `/usr/src/RPM/BUILD/modutils-2.4.21/insmod'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.76637 (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.76637 (%build)
[root@frodo module-init-tools-0.9.3]# ld -v
GNU ld version 2.12.90.0.15 20020717
Do you need further information ?
Ciao,
Paolo
--
______________________________________________
http://www.linuxmail.org/
Now with POP3/IMAP access for only US$19.95/yr
Powered by Outblaze
^ permalink raw reply
* Re: [BK fbdev] Yet again more fbdev updates.
From: James Simmons @ 2002-12-14 0:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christoph Hellwig, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0212131347240.10159-100000@home.transmeta.com>
> James,
> the fbcon update seems to have broken the plain VGA console. I get a page
> fault at vgacon_scroll+0x144, the call sequence seems to be:
>
> vt_console_print+0x203
> set_cursor+0x78
> vgacon_cursor+x0xb5
> scrup+0x122
Calling scrup is out of place. It is only called by lf() and csi_M() in
the vt.c. lf() is used in vt_console_print but it is called before
set_cursor(). Also vgacon_cursor doesn't call vgacon_scroll. It can call
vgacon_scrolldelta. Now scrup does call vgacon_scroll. It looks like The
code jumped from the middle of vt_console_print to scrup. Do you get the
same error all the time? Also do you have Preemptible Kernel turned on?
> vgacon_scroll+0x144
>
> I don't know what triggers it, since it seems to happen pretty randomly.
>
> Linus
>
>
^ permalink raw reply
* [LARTC] Re: Compiling iproute2(w/HTB patch) for 2.5.51
From: axel @ 2002-12-13 23:55 UTC (permalink / raw)
To: lartc
Hi again!
On Sat, 14 Dec 2002, axel@pearbough.net wrote:
> having read an article about QoS and HTB in a German computer magazine I
> wanted to implement such thing on my linux router running kernel 2.5.51.
> First I patched the iproute2-020116.tar.gz package with the htb3.6_tc.diff
> from http://luxik.cdi.cz/~devik/qos/htb/ and started building it. But
> unfortunately it resulted in strange compile errors I do not understand.
>
> make[1]: *** [ss.o] Error 1
> make[1]: Leaving directory /usr/local/src/iproute2/misc'
There are no such problems with 2.4.20.
Axel
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Setting standard arguments
From: axel @ 2002-12-13 23:52 UTC (permalink / raw)
To: whitnl73; +Cc: linux-newbie
In-Reply-To: <20021213.183853.134684296.0.whitnl73@juno.com>
Hi!
On Fri, 13 Dec 2002, whitnl73@juno.com wrote:
> On Thu, 12 Dec 2002 axel@pearbough.net wrote:
> > For example I call "checkinstall" and "checkinstall -S --nodoc --gzman
> > --install=yes" shall be executed.
> > Can this be done somehow with tcsh?
>
> alias checkinstall='checkinstall -S --nodoc --gzman --install=yes'
Thank you very much!
Best regards,
Axel
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* [LARTC] Compiling iproute2(w/HTB patch) for 2.5.51
From: axel @ 2002-12-13 23:49 UTC (permalink / raw)
To: lartc
Hi,
having read an article about QoS and HTB in a German computer magazine I
wanted to implement such thing on my linux router running kernel 2.5.51.
First I patched the iproute2-020116.tar.gz package with the htb3.6_tc.diff
from http://luxik.cdi.cz/~devik/qos/htb/ and started building it. But
unfortunately it resulted in strange compile errors I do not understand.
Hope this is some help for you and I am not doing something terribly wrong.
Best regards,
Axel Siebenwirth
make[1]: Entering directory /usr/local/src/iproute2/misc'
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include-glibc
-I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
-I/usr/src/linux/include -I../include -DRESOLVE_HOSTNAMES -c -o ss.o ss.c
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:9: redefinition of `struct timespec'
/usr/src/linux/include/linux/time.h:15: redefinition of `struct timeval'
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:146:1: warning: "FD_SET" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:89:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:147:1: warning: "FD_CLR" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:90:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:148:1: warning: "FD_ISSET" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:91:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/skbuff.h:19,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/time.h:149:1: warning: "FD_ZERO" redefined
In file included from /usr/include/sys/types.h:215,
from ../include-glibc/glibc-bugs.h:5,
from <command line>:1:
/usr/include/sys/select.h:92:1: warning: this is the location of the
previous definition
In file included from /usr/src/linux/include/linux/sched.h:12,
from /usr/src/linux/include/linux/mm.h:4,
from /usr/src/linux/include/linux/skbuff.h:25,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/linux/jiffies.h:11: parse error before "jiffies_64"
/usr/src/linux/include/linux/jiffies.h:11: warning: type defaults to nt'
in declaration of
iffies_64'
/usr/src/linux/include/linux/jiffies.h:11: warning: data definition has no
type
or storage class
In file included from /usr/src/linux/include/linux/sched.h:20,
from /usr/src/linux/include/linux/mm.h:4,
from /usr/src/linux/include/linux/skbuff.h:25,
from /usr/src/linux/include/linux/tcp.h:20,
from ss.c:36:
/usr/src/linux/include/asm/mmu.h:13: field `sem' has incomplete type
/usr/src/linux/include/asm/mmu.h:15: confused by earlier errors, bailing out
make[1]: *** [ss.o] Error 1
make[1]: Leaving directory /usr/local/src/iproute2/misc'
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.