* Re: HPT372 RAID controller
From: Spacecake @ 2002-12-10 18:09 UTC (permalink / raw)
To: Alan Cox; +Cc: sflory, linux-kernel
In-Reply-To: <1039480307.12051.8.camel@irongate.swansea.linux.org.uk>
Hi,
> Check the notes on -ac kernels when doing this. I try and note when
> stuff is stable or not
Because of a recent crash (the first ever using linux on this hardware,
using 2.4.18 through 2.4.20), i went in search of these release notes. I
feel really stupid here, but i can't find them, not on
linux.org.uk/thefreeworld.net, google, kernel.org... umm?
The crash in question was while copying between hard disks (both on the
RAID controller) a directory tree of MP3s, about 95megs. I was in X at
the time so i couldn't see any errors if there was some, and the machine
totally locked up, tried pinging it etc, didn't work.
Can't find any errors in logfiles or anything.
The .config for the kernel was identical to my 2.4.20 config that has
never crashed, except it has IDE Taskfile IO enabled, because from the
help this seemed like a good thing.
Do you want me to provide debugging info on this? It's okay if not, i'll
just wait until stuff works in the main stable kernel :)
Thanks,
- Daniel
P.S. please CC any replies to me, i'm no longer subscribed to LKML.
^ permalink raw reply
* Re: [BUG]: agpgart for i810 chipsets broken in 2.5.51
From: Antonino Daplas @ 2002-12-10 21:00 UTC (permalink / raw)
To: Dave Jones; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <20021210170542.GB577@codemonkey.org.uk>
On Tue, 2002-12-10 at 22:05, Dave Jones wrote:
> On Tue, Dec 10, 2002 at 05:06:17PM +0000, Alan Cox wrote:
> > Given how fragile the AGP code can be I would much rather we had the AGP
> > continue to initialize late. If the AGP init function is something like
> >
> >
> > int agp_required(void)
> > {
> > static int agp_inited = 0;
> >
> > if(!agp_inited)
> > {
> > agp_inited = 1;
> > agp_do_real_init();
> > }
> > }
> >
> > module_init(agp_required);
> >
> >
> > Then the i810 fb driver can do
> >
> > agp_required();
> >
> > and force the order change only if necessary.
>
> That works for me. It's not ideal, but it's the cleanest
> solution suggested so far. I'll hack a check into
> agp_init() to do this, which should allow us to close bug #20 [*]
>
Oops, Alan beat me into it. It's basically the same as what I've got
except I had an i810fb specific macro. I guess the one without the
macro is cleaner.
Tony
diff -Naur linux-2.5.51/drivers/char/agp/backend.c linux/drivers/char/agp/backend.c
--- linux-2.5.51/drivers/char/agp/backend.c 2002-12-10 20:46:58.000000000 +0000
+++ linux/drivers/char/agp/backend.c 2002-12-10 20:46:26.000000000 +0000
@@ -269,7 +269,7 @@
return 0;
}
-int __init agp_init(void)
+int __init do_agp_init(void)
{
memset(&agp_bridge, 0, sizeof(struct agp_bridge_data));
agp_bridge.type = NOT_SUPPORTED;
@@ -279,6 +279,25 @@
return 0;
}
+#ifdef CONFIG_FB_I810
+int __init agp_init(void)
+{
+ static int agp_has_init = 0;
+
+ if (agp_has_init)
+ return 0;
+
+ agp_has_init = 1;
+
+ return do_agp_init();
+}
+#else
+static int __init agp_init(void)
+{
+ return do_agp_init();
+}
+#endif
+
#ifndef CONFIG_GART_IOMMU
module_init(agp_init);
#endif
diff -Naur linux-2.5.51/drivers/char/agp/intel-agp.c linux/drivers/char/agp/intel-agp.c
--- linux-2.5.51/drivers/char/agp/intel-agp.c 2002-12-10 20:47:03.000000000 +0000
+++ linux/drivers/char/agp/intel-agp.c 2002-12-10 20:46:23.000000000 +0000
@@ -1470,7 +1470,7 @@
.probe = agp_intel_probe,
};
-static int __init agp_intel_init(void)
+static int __init do_agp_intel_init(void)
{
int ret_val;
@@ -1487,6 +1487,25 @@
pci_unregister_driver(&agp_intel_pci_driver);
}
+#ifdef CONFIG_FB_I810
+int __init agp_intel_init(void)
+{
+ static int intel_agp_has_init = 0;
+
+ if (intel_agp_has_init)
+ return 0;
+
+ intel_agp_has_init = 1;
+
+ return do_agp_intel_init();
+}
+#else
+static int __init agp_intel_init(void)
+{
+ return do_agp_intel_init();
+}
+#endif
+
module_init(agp_intel_init);
module_exit(agp_intel_cleanup);
^ permalink raw reply
* Re: [BUG]: agpgart for i810 chipsets broken in 2.5.51
From: Antonino Daplas @ 2002-12-10 21:01 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021210161725.GA577@codemonkey.org.uk>
On Tue, 2002-12-10 at 21:17, Dave Jones wrote:
> On Wed, Dec 11, 2002 at 12:07:45AM +0500, Antonino Daplas wrote:
> > > That chunk of X code is crap. So much so, that someone even put a
> > > comment there (not that what they suggested was much better).
> > >
> > > See line 122 of http://www.atomised.org/docs/XFree86-4.2.1/agp_8c-source.html
> > >
> > Ouch. That's a sh??ty version check. And it has to be present from
> > 4.0.0 to 4.2.1, and if they don't correct it, 4.3.0.
>
> Andreas Schwab pointed out to me, that due to the broken boolean check,
> I can bump the version to 0.100 and it'll work. At least until the
> X folks change/remove that code.
I've tested using version 0.100 and it works just fine.
Tony
^ permalink raw reply
* Re: Re: documentation or lack thereof
From: Patrick Shirkey @ 2002-12-10 17:59 UTC (permalink / raw)
Cc: alsa-devel
In-Reply-To: <E18LQai-0006m2-00@sc8-sf-list1.sourceforge.net>
Paul Davis wrote:
> i disagree. there seem to be very few people interested in working on
> alsa-kernel or alsa-lib. most people want a nice, easy to use API so
> that they can dump sounds to an audio interface or possibly record
> them. the number of people with the skills, knowledge and interest in
> working on ALSA has always been remarkably low.
>
> on the other hand, having more documentation is almost always a good
> thing. now, where are the volunteers?
>
Lot's of possible flames here but the main thing is that the people who
do understand the alsa-driver well enough are either too busy to find
the time or have justifiable reservations about getting their prose online.
Mailing lists are much better for these people than official documents.
Unfortunately the people like myself are not in a position to edit large
amounts of code documentation which we scour from the lists. I can
however do a reasonable attempt at formatting the stuff. However I don't
have much time or inclination to learn docbook at the moment so it
wouldn't be a standard format.
But it will probably help people if I put the basics up on line. So I
will do some work on it over the next few days.
AFAIK there is only one other person round here who has the motivation
and skills to do the docbook work and he must be busy at the moment or
found other things to do.
Anyway against all odds the past year has netted us the alsa-docs,
alsa-wiki, Paul and Matthias's basic programming howtos, Takashi's
desription of how to build a driver which equal 5 new docs. Not bad at all.
The only thing we need now is an indepth doc on doing midi programming
which Juan Linetsky has started but has declined offering it to the public.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply
* Re: hard drive head parking in linux
From: ichi @ 2002-12-10 17:58 UTC (permalink / raw)
To: Jerry James Haumberger; +Cc: linux-newbie
In-Reply-To: <200212092132.OAA04397@cu.imt.net>
Jerry James Haumberger wrote:
>
> I understand that early PC hard drives had to have
> their heads parked when shut down,
A blast from the past. Yes, indeed, pre-IDE drives
(two data cables) needed parking. Over the years I've
had several of these monsters. I even installed a small
Linux on one (it had to be small 'cause the HD was only
20mb :-). Did you know that the latest Slackware (8.1)
still provides a stock kernel (xt.i) for such drives?
Imagine that: a 2.4.18 kernel on an old Seagate MFM.
> Jerry... on a 486 DX2-50MHz with 8MB RAM in BasicLinux 1.7
> and Midnight Commander at the lab of Classic Systems, Ltd.
You gotta give credit to Jerry. He doesn't just talk the
talk, he walks the walk. A close reading of his message
header reveals that he is indeed using a minimalist mailer
for this list.
Cheers,
Steven
-
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
* Re: Port Forwarding only works outside?
From: Andrea Rossato @ 2002-12-10 17:53 UTC (permalink / raw)
To: netfilter
In-Reply-To: <97AE76F7052DBB43A268427FCAAEF0371BF6D1@s-2k-corp1.bass-inc.com>
iptables -A POSTROUTING -o eth1 -j MASQERADE
you need to change source address of the forwarded traffic, so that it
can go back for the same way it came in from.
andrea
>
Todd Hartman wrote:
> I tried the suggestion and I'm sorry to say that it didn't work either. I
> realize I didn't give very exacting details on what we had already. I'll do
> that now. Here's the /etc/sysconfig/iptables file I'm currently working
> with. This was generated through the webmin interface.
>
> # Generated by iptables-save v1.2.5 on Tue Dec 10 10:52:38 2002
> *nat
> :OUTPUT ACCEPT [0:0]
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> -A POSTROUTING -o eth0 -j MASQUERADE
> -A PREROUTING -p tcp -m tcp -i eth0 --dport 25 -j DNAT --to-destination
> 192.168.1.29:25
> COMMIT
> # Completed on Tue Dec 10 10:52:38 2002
> # Generated by iptables-save v1.2.5 on Tue Dec 10 10:52:38 2002
> *mangle
> :PREROUTING ACCEPT [272:72783]
> :INPUT ACCEPT [6571:1221017]
> :FORWARD ACCEPT [2516:1428106]
> :OUTPUT ACCEPT [296:174336]
> :POSTROUTING ACCEPT [7989:3971198]
> COMMIT
> # Completed on Tue Dec 10 10:52:38 2002
> # Generated by iptables-save v1.2.5 on Tue Dec 10 10:52:38 2002
> *filter
> :INPUT ACCEPT [273:72823]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [296:174336]
> COMMIT
> # Completed on Tue Dec 10 10:52:38 2002
>
> I have another server at home that's doing pretty much the same thing with
> different ports (for games on a machine behind the firewall) and that's
> working fine. If I change that 192.168.1.29:25 to my home server's IP, it
> forwards just fine. Also, on this firwall, I can telnet to 192.168.1.29 25
> but I can't seem to forward to it.
>
> -T
>
> -----Original Message-----
> From: Sander Sneekes [mailto:sander@dmdsecure.com]
> Sent: Tuesday, December 10, 2002 10:29 AM
> To: Todd Hartman
> Cc: 'netfilter@lists.netfilter.org'
> Subject: Re: Port Forwarding only works outside?
>
>
> try
>
> iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE iptables -A
> FORWARD -p tcp --dport 25 -d 192.168.1.29 -j ACCEPT iptables -A PREROUTING
> -t nat -p tcp --dport 25 -d x.x.x.x -j DNAT --to 192.168.1.29
>
> x.x.x.x = eth0 external ip
>
> On Tue, 2002-12-10 at 16:31, Todd Hartman wrote:
>
>>I've come across an issue I just don't know how to solve. I'm not even
>>certain it's an issue with iptables itself, but I thought that someone
>>here might have run across this before and have some advice.
>>
>>I've got a RH7.3 box set up with two NICs. Eth0 is external and eth1
>>is internal. Internal network is 192.168.1.* with netmask
>>255.255.255.128. I need to forward traffic on eth0, port 25 to
>>192.168.1.29. The firewall is 192.168.1.1 - both in the same subnet as
>>I understand it.
>>
>>When I forward SMTP traffic to 192.168.1.29 and try to telnet to port
>>25 to test SMTP, it just sits there, unresponsive. BUT, if I forward
>>eth0 port 25 traffic to a machine out on the internet, it works just
>>fine.
>>
>>I suspect a networking problem, but I don't know well enough to pin it
>>down myself.
>>
>>-T
>>
>
>
^ permalink raw reply
* RE: 8xx_io/enet.c
From: Stephan Linke @ 2002-12-10 17:52 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: Linuxppc-Embedded
In-Reply-To: <IGEFJKJNHJDCBKALBJLLMELCFIAA.joakim.tjernlund@lumentis.se>
Hi,
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@lumentis.se]
> Sent: Dienstag, 10. Dezember 2002 16:47
> To: Stephan Linke
> Subject: RE: 8xx_io/enet.c
>
>
> >
> > Hi,
> >
> > just checked the mailing list for the patches. Looks like you
> mean the 'copy
> > large buffers' patch.
> > I took the second version and applied it to fec.c too.
> > It works fine on both devices. The only thing that confused me was the
> > discussion about the possibility of inconsistent data.
>
> Thats the one. However there is a small bug in version 2 w.r.t when the
> invalidate_dcache_range call is made. In the second version the
> call is made
> AFTER the buffer has been received as opposed in my first version
> where the
> call is made BEFORE handing over the buffer to the CPM. That may in some
> rare case corrupt the packet. See
> http://lists.linuxppc.org/linuxppc-embedded/200211/msg00120.html
>
> This is only relevant for 8xx, 82xx don't have to invalidate.
>
> > But we didn't noticed
> > any performance impact when testing it with IP packets.
>
> Didn't you get any performace increase after appling my patch?
> If you did, could you send me your performace numbers?
> Did you try the first version also? If so,any performance
> difference compared with version 2?
>
> Jocke
Indeed we had a better performance with the patch applied to fec.c
(100base-Tx). Unfortunately I don't have the results at the moment. At
enet.c I didn't noticed mutch of a difference since handling 10base-T
traffic isn't that mutch of a problem at the moment and I didn't spend time
to figure out the exact CPU load.
I remember that someone said he had an performance impact at small packets.
I didn't noticed any (even though there must be a slight on caused by the
additinal if-statement).
I can post some of our results results after I did some more tests but that
may take a while since I am buisy with other stuff at the moment.
Stephan
>
> PS.
> Any perticular reason not to cc the embedded list also? Others would
> probably be intressted also.
>
Well, there is a 'reason'. I simply didn't payed attention to the fact that
a simple reply doesn't reply to the list.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Regarding consistent_alloc
From: Tom Rini @ 2002-12-10 17:49 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Dan Malek, Paul Mackerras, joakim.tjernlund, Matt Porter,
linuxppc-embedded
In-Reply-To: <3DF45D05.5030003@intracom.gr>
On Mon, Dec 09, 2002 at 11:06:13AM +0200, Pantelis Antoniou wrote:
[snip]
> Since I'm the one that started this thread let me make a few points.
>
> 1. The comment that consistent_alloc is tied to the PCI bus is valid,
> since the dma_handle is returned by a call to virt_to_bus(), with
> the virt_to_bus() being:
>
> /*
> * The PCI bus is inherently Little-Endian. The PowerPC is being
> * run Big-Endian. Thus all values which cross the [PCI] barrier
> * must be endian-adjusted. Also, the local DRAM has a different
> * address from the PCI point of view, thus buffer addresses also
> * have to be modified [mapped] appropriately.
> */
> extern inline unsigned long virt_to_bus(volatile void * address)
> {
> #ifndef CONFIG_APUS
> if (address == (void *)0)
> return 0;
> return (unsigned long)address - KERNELBASE + PCI_DRAM_OFFSET;
> #else
> return iopa ((unsigned long) address);
> #endif
> }
This is typically used by PCI, but look at the code for the !CONFIG_APUS
(ie just about every machine, including all 8xx) case. This is the
iopa, that if classes haven't made me even more incoherent, that has
been mentioned throught the thread.
> Also the consistent_sync() takes as a direction argument values like
> PCI_DMA_FROMDEVICE.
This is unfortunate, but 'expected' for now. These constants really
have nothing to do with PCI DMA, but DMA in general. There was a hope
of fixing that in 2.5, but I don't recall if it happened (it might
have) yet.
> It has something obviously to do with a PCI bus. My board, and I believe
> most of the boards with a 8xx do not have a PCI bus.
>
> Is it possible to modify consistent_alloc to be something more
> generic?
It is already generic, it's just not obvious :(
> 2. I have a requirement to have my drivers loaded as modules.
> m8xx_cpm_hostalloc has a very simplistic implementation, which
> makes it unsuitable for something like that. I have some patches
> that fix both m8xx_cpm_hostalloc and 8xx_cpm_dpalloc by implementing
> a proper heap, with free space management and coalescing.
> What is the proper way to push them, and to whom?
<buck passing mode=on>Dan Malek still knows the most about the
8xx-specific portions of the kernel, so he should really speak up here
when he gets a moment</buck passing>
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [2.5.51, FB] missing EXPORT_SYMBOL(fb_blank) in fbmem.c
From: James Simmons @ 2002-12-10 18:48 UTC (permalink / raw)
To: Jochen Hein; +Cc: linux-kernel
In-Reply-To: <E18Lmj7-00011o-00@gswi1164.jochen.org>
> I compiled fbcon and neofb as modules, when loading fbcon I get:
>
> root@gswi1164:~# modprobe fbcon
> fbcon: Unknown symbol fb_blank
> FATAL: Error inserting fbcon (/lib/modules/2.5.51/kernel/fbcon.ko): Unknown symbol in module
Oops. One of those last minute changes which I didn't test with a modular
setup. Will fix right away.
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
^ permalink raw reply
* Expeiment with a simple boot?
From: Matt Young @ 2002-12-10 17:54 UTC (permalink / raw)
To: linux-kernel
Using 2.5.50 is there a boot procedure such as:
Turn off DEVFS and INITRDFS then specify the root device with major and minor
numbers in the linux command line, (using grub)
^ permalink raw reply
* Re: [Linux-ia64] Re: Configurable NUMA node memory size
From: Jesse Barnes @ 2002-12-10 17:46 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805530@msgid-missing>
On Tue, Dec 10, 2002 at 06:35:04PM +0100, Erich Focht wrote:
> On Tuesday 10 December 2002 02:33, Jesse Barnes wrote:
> > Erich, could you please check out the discontig bits (mmzone.h) in the
> > SN update patch I posted today? I renamed DIG_BANKSHIFT to just
> > BANKSHIFT so it could be reused, but I'm not sure if I did it correctly.
>
> Looks good. Renaming is fine with me. I guess you'll have to rediff
> the patch for David in case he takes the configurable banksize in.
Great, thanks Erich. Hopefully David will take your change since I have
to rediff anyway.
Jesse
^ permalink raw reply
* RE: Port Forwarding only works outside?
From: Brad Morgan @ 2002-12-10 17:43 UTC (permalink / raw)
To: Sander Sneekes, Todd Hartman; +Cc: netfilter
In-Reply-To: <1039537731.7136.10.camel@sander>
Given the netmask in the original post I think the first rule should be:
iptables -t nat -A POSTROUTING -s 192.168.1.0/25 -j MASQUERADE
Regards,
Brad
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Sander Sneekes
Sent: Tuesday, December 10, 2002 9:29 AM
To: Todd Hartman
Cc: 'netfilter@lists.netfilter.org'
Subject: Re: Port Forwarding only works outside?
try
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
iptables -A FORWARD -p tcp --dport 25 -d 192.168.1.29 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp --dport 25 -d x.x.x.x -j DNAT --to
192.168.1.29
x.x.x.x = eth0 external ip
On Tue, 2002-12-10 at 16:31, Todd Hartman wrote:
> I've come across an issue I just don't know how to solve. I'm not even
> certain it's an issue with iptables itself, but I thought that someone
> here might have run across this before and have some advice.
>
> I've got a RH7.3 box set up with two NICs. Eth0 is external and eth1
> is internal. Internal network is 192.168.1.* with netmask
> 255.255.255.128. I need to forward traffic on eth0, port 25 to
> 192.168.1.29. The firewall is 192.168.1.1 - both in the same subnet as
> I understand it.
>
> When I forward SMTP traffic to 192.168.1.29 and try to telnet to port
> 25 to test SMTP, it just sits there, unresponsive. BUT, if I forward
> eth0 port 25 traffic to a machine out on the internet, it works just
> fine.
>
> I suspect a networking problem, but I don't know well enough to pin it
> down myself.
>
> -T
>
^ permalink raw reply
* Re: pci.agent remove
From: Stephen Williams @ 2002-12-10 17:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-103951971717701@msgid-missing>
eoa@cs.hmc.edu said:
> After poking at some of the neighboring files, I added a remove case
> to the action section, and I thought I'd give it to you guys in case
> it proved useful to anyone.
Wouldn't it be better to support remove via the REMOVER interface,
as is done for USB? The remover spares the system a lookup by
allowing the add to bind a script to the device when it is added.
Much faster.
See etc/hotplug/usb.agent, and look in the comments for the
REMOVER variable, and the remove) action in the case statement.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: 2.5.51 won't boot with devfs enabled
From: Mohamed Amr Elayouty @ 2002-12-10 17:50 UTC (permalink / raw)
To: linux-kernel
Eric I have a bug open on bugzilla for this.
The only workaround I know is by enabling CONFIG_UNIX98_PTYS=Y under
character devices.
Mohamed El Ayouty
^ permalink raw reply
* Oops on linux 2.4.20-ac1
From: Orion Poplawski @ 2002-12-10 17:49 UTC (permalink / raw)
To: linux-kernel
I've been having a number of issues, mostly system lockups, with a
machine of ours - a dual proc athlon. I've removed some hardware and I
haven't seen a hand recently. However, we got an Oops message recently.
I lost that message because it wasn't written to any log (any way I can
fix that?). So, I upgraded the kernel to 2.4.20-ac1. Under that I
started getting Oops quite frequently. Here is my first attemp at
processing the message. Note that I switched back to the previous
kernel, but it's running the same module list and I tried to point
ksymoops to the correct pieces. I also typed the oops message in from
what I wrote down from the screen. Please let me know if I made a
mistake there.
ksymoops 2.4.1 on i686 2.4.19. Options used
-v /usr/src/linux-2.4.20-ac1/vmlinux (specified)
-k /var/log/ksyms.1 (specified)
-l /proc/modules (default)
-o /lib/modules/2.4.20-ac1 (specified)
-m /boot/System.map-2.4.20-ac1 (specified)
Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/sym53c8xx.o) for sym53c8xx
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod
ksymoops: No such file or directory
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/net/ipv4/netfilter/netfilter.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/net/fc/fc.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/sound/sounddrivers.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/cdrom/driver.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/ide/raid/idedriver-raid.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/ide/ppc/idedriver-ppc.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/ide/legacy/idedriver-legacy.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/ide/arm/idedriver-arm.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/misc/misc.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/parport/driver.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/media/radio/radio.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/media/video/video.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/media/media.o
Warning (read_object): no symbols in
/lib/modules/2.4.20-ac1/build/drivers/hotplug/vmlinux-obj.o
Warning (compare_ksyms_lsmod): module 3c59x is in lsmod but not in
ksyms, probably no symbols exported
Warning (compare_ksyms_lsmod): module autofs is in lsmod but not in
ksyms, probably no symbols exported
Warning (compare_ksyms_lsmod): module binfmt_misc is in lsmod but not in
ksyms, probably no symbols exported
Warning (compare_ksyms_lsmod): module lockd is in lsmod but not in
ksyms, probably no symbols exported
Warning (compare_ksyms_lsmod): module nfs is in lsmod but not in ksyms,
probably no symbols exported
Warning (compare_ksyms_lsmod): module nfsd is in lsmod but not in ksyms,
probably no symbols exported
Warning (compare_ksyms_lsmod): module sunrpc is in lsmod but not in
ksyms, probably no symbols exported
Warning (map_ksym_to_module): cannot match loaded module ext3 to a
unique module object. Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module jbd to a unique
module object. Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module sym53c8xx to a
unique module object. Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module sd_mod to a
unique module object. Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module scsi_mod to a
unique module object. Trace may not be reliable.
Oops: 0002
CPU: 0
EIP: 0010:[<f89641eb>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010216
eax: 00000040 ebx: 00000028 ecx: 00000060 edx: f590a960
esi: f590a800 edi: f590a960 ebp: c4650ed2 esp: f4a45eb0
ds: 0018 es: 0018 ss: 0018
Stack: 0000003c 0000001f 00000000 0000b800 00000060 f590a960 f5e4d62c
00000082
00000001 00000082 f5dd3fd8 00000001 00000086 00000001 00000086
f5a98000
00000000 0000000e f4a45f08 00000000 f5a4d600 f7ff0340 00000040
c01beaff
Call Trace: [<c01beaff>] [<c0120593>] [<f896382a>]
[<c011f92d>] [<c0109b89>] [<c0109cf8>]
Code: b8 01 30 00 00 83 c2 0e 66 ef 8b 7c 24 14 8b 87 dc 00 00 00
>>EIP; f89641eb <END_OF_CODE+10598c/????> <=====
Trace; c01beaff <netif_receive_skb+ff/130>
Trace; c0120593 <send_sig_info+73/90>
Trace; f896382a <END_OF_CODE+104fcb/????>
Trace; c011f92d <do_timer+3d/70>
Trace; c0109b89 <handle_IRQ_event+39/60>
Trace; c0109cf8 <do_IRQ+68/b0>
Code; f89641eb <END_OF_CODE+10598c/????>
00000000 <_EIP>:
Code; f89641eb <END_OF_CODE+10598c/????> <=====
0: b8 01 30 00 00 mov $0x3001,%eax <=====
Code; f89641f0 <END_OF_CODE+105991/????>
5: 83 c2 0e add $0xe,%edx
Code; f89641f3 <END_OF_CODE+105994/????>
8: 66 ef out %ax,(%dx)
Code; f89641f5 <END_OF_CODE+105996/????>
a: 8b 7c 24 14 mov 0x14(%esp,1),%edi
Code; f89641f9 <END_OF_CODE+10599a/????>
e: 8b 87 dc 00 00 00 mov 0xdc(%edi),%eax
26 warnings and 5 errors issued. Results may not be reliable.
^ permalink raw reply
* Re: radeonfb and 2.5.51
From: James Simmons @ 2002-12-10 18:41 UTC (permalink / raw)
To: Hanno Böck; +Cc: linux-kernel
In-Reply-To: <20021210180046.6e7c31ed.hanno@gmx.de>
> I tried to compile the latest 2.5.51, but radeonfb brings errors.
> I defined all missing PCI_DEVICE_ID_ATI_RADEON things, but still get a compile error about wrong definition of the display-type.
> Is there a fix available?
A fix is in the works. I would have fixed some time ago but lack that
hardware.
^ permalink raw reply
* Re: (no subject)
From: James Simmons @ 2002-12-10 18:31 UTC (permalink / raw)
To: Vincent Ivens; +Cc: linux-fbdev-devel
In-Reply-To: <1039517959.3df5c9075f91e@berflo.dhs.org>
> New to the list, is this an appropriate place to ask basic question about
> framebuffer divices?
>
> for example:
> what are the basic funtions i can expect in a framebuffer?
WHat do you mean? Functionality from a userland perspective or from inside
the kernel. Which version of the kernel are you looking at?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply
* Re: 2.5.51 won't boot with devfs enabled
From: Serge Kuznetsov @ 2002-12-10 17:44 UTC (permalink / raw)
To: Dave Jones, ebuddington; +Cc: linux-kernel
In-Reply-To: <20021210170939.GC577@codemonkey.org.uk>
> > I had the same problem with 2.5.50, avoidable by disabling devfs entirely.
>
> Sounds similar to http://bugzilla.kernel.org/show_bug.cgi?id=110
> Does enabling UNIX98 pty's fix your problem ?
I have the same issue, even with
CONFIG_UNIX98_PTYS = Y
CONFIG_DEVFS_FS = Y
CONFIG_DEVFS_MOUNT = Y
CONFIG_DEVFS_DEBUG = Y
CONFIG_DEVPTS_FS = Y
I am trying to invistigate problem closely for now.
All the Best!
Serge.
^ permalink raw reply
* Re: [Linux-ia64] Re: Configurable NUMA node memory size
From: Erich Focht @ 2002-12-10 17:35 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805530@msgid-missing>
On Tuesday 10 December 2002 02:33, Jesse Barnes wrote:
> Erich, could you please check out the discontig bits (mmzone.h) in the
> SN update patch I posted today? I renamed DIG_BANKSHIFT to just
> BANKSHIFT so it could be reused, but I'm not sure if I did it correctly.
Looks good. Renaming is fine with me. I guess you'll have to rediff
the patch for David in case he takes the configurable banksize in.
Regards,
Erich
^ permalink raw reply
* Re: ECN target bug report
From: Andrea Rossato @ 2002-12-10 17:27 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <3DF52111.8080405@trash.net>
Patrick McHardy wrote:
> the first attached patch fixes the issue you reported (verified),
> altough i'm not entirely sure why ;).
> the second one is untested but probably couldn't hurt neither.
great patrick! faster then light!
BTW, your second patch seems to imply that byte order is just a matter
of taste ;)
iph and tcph should give little endian int on i386 arch, so tons should
be needed when writing to the sk_buff. but in computer programming there
are misteries a lawyar will never be able to grasp...
thanks a lot.
andrea
^ permalink raw reply
* Re: Canot get serial card working: It worked ONCE.
From: Curt Mills, WE7U @ 2002-12-10 17:27 UTC (permalink / raw)
To: mvw; +Cc: Linux-Hams
In-Reply-To: <Pine.LNX.4.44.0212101039080.29662-100000@jeeves.mvw.net>
On Tue, 10 Dec 2002 mvw@mvw.net wrote:
> I did this and it worked once (I used minicom and was able to talk
> successfully to the TNC). I then did kissattach (which should be
> irrelevant, this should not survive a reboot and believe me, I;ve rebooted
> plenty). IN any case, it never worked again: now, when I try, I see
> nothing (no errors either). A breakout box shows no activity on pin 2 and
> RTS (pin 4) inactive (should be active). So the port may think it is not
> on.
I can think of a few possibilities right off:
1) A lock file may have been created for that port, and your
kissattach statement may not be able to delete it and take over the
port. Check areas like /var/lock, /var/spool/lock, etc for
lockfiles.
2) Some other program (gpm?) is using that port.
3) Permissions on the /dev/cua0 or /dev/ttyS0 device may not be set
properly for that user, or perhaps you haven't added that user to
the "uucp" group (another way of handling permissions for that
port).
Is this an unusual card that might require special techniques to set
up?
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
^ permalink raw reply
* Re: Linux 2.5.51 (fbcon issues)
From: James Simmons @ 2002-12-10 18:24 UTC (permalink / raw)
To: CaT; +Cc: Kernel Mailing List
In-Reply-To: <20021210062258.GA667@zip.com.au>
> I removed both and it works fine. thanks. :)
Yeah!!!
> It also seems a lot faster then the 2.4.x version which is way-cool. :)
I know :-) With the help of Antonino Daplas we really go fast code. The
benchmarks show a 2.5.x to 3x improvement over fbcon-cfb*!!! The accelerated
drivers blows the benchmarks away!!!!
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
^ permalink raw reply
* Re: terminal problems with escape characters
From: Miguel González Castaños @ 2002-12-10 17:21 UTC (permalink / raw)
To: linux-admin
In-Reply-To: <Pine.LNX.4.44.0212101255080.2146-100000@bak.amgad.org>
Many thanks for the fancy telnet client.
I am going to specify my problem a little bit more:
I have set TERM to 'linux'.
When I edit with the vi program (or the bash prompt) delete and backspace works fine,
but not control characters, like
the Up, Down, Left,Right arrow keys, instead of that I get:
^[[B , ^[[A , ^[[C , ^[[D
I hope this is a more specific information on this issue. I have looked around in some
web sites, but I still cant figure
out how to fix it.
Many thanks
Miguel
amgad fahmy ha escrito:
> Hello
> Dave telnet is my friend
> it is very flexible & open source
> try it & let se if you still having any problems
>
> http://prdownloads.sourceforge.net/dtelnet/dt118b16.zip?download
>
> On Tue, 10 Dec 2002,
> Miguel González
> Castaños
> wrote:
>
> > Date: Tue, 10 Dec 2002 17:19:34 +0100
> > From: Miguel González Castaños <mgc@tid.es>
> > To: linux-admin@vger.kernel.org
> > Subject: terminal problems with escape characters
> >
> > I have a RedHat 7.3 linux box. I have enabled the telnet server.
> >
> > I am trying to telnet my linux box from a unix-like system where the default
> > terminal setting is set to ansi.
> >
> > I have succesfully changed the setting for the TERM variable to 'linux' or 'vt100'
> > or even 'xterm' (as I have found in several news).
> >
> > But I am still experiencing when I edit files with the vi program, because of the
> > escape characters like the ones to move the cursor dont work...That´s my main
> > problem.
> >
> > Anyway, I have thought that maybe it was due that I was telneting to the Unix box
> > using the Windows 2000 telnet, but I have tried to use other telnet programs
> > (like putty), but I cant figure out what I have to change in the linux box
> > settings (or the telnet client)...
> >
> > Many thanks in advance...
> >
> > Miguel
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> Amgad Fahmy
> >From the Server
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Anti-virus for Sendmail
From: Scott Taylor @ 2002-12-10 17:21 UTC (permalink / raw)
To: linux-admin
In-Reply-To: <200212110002.39658.manoj@tacitnetworks.com>
At 09:02 PM 12/10/02, Manoj Sharma wrote:
>Hello All,
>
>I need suggestions for a Anti-virus for my mail server
>(Running Sendmail on RedHat Linux)
This is not an anti-virus but, virus prevention and management:
http://www.impsec.org/email-tools/procmail-security.html
John Hardin has come up with a great system for sanitizing email through
Procmail, which your undisclosed version of Sendmail and RedHat are
probably already set up for. His Sanitizer is very useful, effective and
configurable.
There is a user group listed on his site which may be useful when setting
it all up and clarifying some terms and instructions you may find
there. Oh, it's also very easy to setup, although you may want to do some
things differently then the defaults.
Hope this helps.
Scott.
^ permalink raw reply
* Re: [parisc-linux] new 2.4.20-pa10 kernel: boot pb.
From: Bruno Vidal @ 2002-12-10 16:54 UTC (permalink / raw)
Cc: Randolph Chung, parisc-linux@lists.parisc-linux.org
In-Reply-To: <3DF456D5.7E000273@admin.france.hp.com>
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
Hi
I didn't find anything new about this pb. It is hanging in the scan of
the bus while in scan_scsis_single(). I've tried to recompile 2.4.19-pa20
and it works fine ???? So what change beetween 2.4.19 and 2.4.20 in this
area ?
thanks.
--
Vidal Bruno, (770-4271)
SSD-HA Team, HP-UX & LINUX Support
bruno_vidal@admin.france.hp.com
[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]
begin:vcard
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard
^ 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.