* "Segmentation fault"message
From: yamazaki @ 2002-12-13 5:01 UTC (permalink / raw)
To: linuxppc-embedded
hi.
we made custom board(cpu is MPC8245)
kernel is 2.4.18
our application sometimes stop with the message "Segmentation fault"or
"illegal instruction".
So i searched this message on kernel source code by grep command.
But i could not find this message "Segmentation fault".
somebody tell me where i can find this message "Segmentation fault"and
"illegal instruction".
----
yamazaki yama@isd.mci.mei.co.jp
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH] fix offb
From: James Simmons @ 2002-12-13 5:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linux Kernel Mailing List, Linux Fbdev development list
In-Reply-To: <15864.1613.688767.520790@argo.ozlabs.ibm.com>
All the patches have been applied :-)
^ permalink raw reply
* Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).
From: James Simmons @ 2002-12-13 5:09 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Miles Lane, Linux Fbdev development list
In-Reply-To: <1039705243.1006.1.camel@localhost.localdomain>
> Can you test the attached patch (rivafb1.diff)? It fixes some things:
I tested the patch. The colors are still messed up :-( I'm running at 8
bpp mode. I applied the patch since it fixed some important things.
I also add support and more functionality. I still have some to go.
-------------------------------------------------------
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
* [Linux-ia64] Re: [Pcihpd-discuss] Problem with pci_read_config_word_nodev in 2.4.20
From: Greg KH @ 2002-12-13 5:12 UTC (permalink / raw)
To: linux-ia64
On Fri, Dec 13, 2002 at 03:05:33AM +0000, Matthew Wilcox wrote:
>
> I'm trying to get the acpiphp driver going on an HP system.
> Unfortunately, it crashes the machine on zx1 systems due to uninitialised
> sysdata. I'm using the 2.4.20 patch from Bjorn, plus the 0.4 acpiphp
> driver that was submitted for 2.4.21.
>
> Here's the problem:
>
> acpiphp_enable_slot()
> |-> enable_device()
> |-> acpiphp_configure_slot()
> |-> pci_read_config_byte_nodev()
> |-> build_dev()
> |-> pci_read_config_byte(dev)
> |-> dev->bus->ops->read_byte()
>
> And the zx1 read_byte operation attempts to dereference a struct which
> sysdata points to. But build_dev() doesn't fill in sysdata, and it has
> no easy way to get it.
Um, didn't we go over all of this a few weeks ago? :)
In the end, yes, it's a problem. And yes, I'd like to fix it. But I
haven't gotten a patch from anyone that fixes this correctly. The only
one I've seen that is halfway sane just sets sysdata to 0, but that
only works on one machine type :)
> I really don't know the best way to fix this. Part of me says to fix
> the _nodev() API to take a struct pci_bus *. Part of me says that's too
> big for 2.4 and not necessary for 2.5. So maybe we should stash the sysdata
> in the acpiphp_bridge.
Yes, for 2.5 this is not a problem. The _nodev() functions are big
already, we could merge slot and function together to devfn, and then
add another argument if we want to keep it at 6 paramaters...
Any other ideas are welcome.
thanks,
greg k-h
^ permalink raw reply
* Re: dmfs for 2.5.51
From: Greg KH @ 2002-12-13 5:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: lvm-devel, linux-kernel
In-Reply-To: <3DF93CC9.979CA988@digeo.com>
On Thu, Dec 12, 2002 at 05:50:01PM -0800, Andrew Morton wrote:
> Greg KH wrote:
> >
> > ..
> > +Examples
> > +--------
> > +
> > +Example commands will make things a bit clearer:
>
> hm. The whole thing seems hokey to me. Not sure why.
I agree. It doesn't feel right. I mean, doing a mkdir(1) to create a
device, which causes files to be created automagically in that
directory? Something needs to change here, and I proposed a single file
to write to that creates the device, but was shot down by the author.
Anyone else have any ideas?
> > ...
> > + echo -e "0 56 linear /dev/hda3 0\n56 102344 linear /dev/hda4 0" > table
>
> Maybe this is why.
Heh, yeah, welcome to parsers in the kernel :)
But the dm code today does much the same thing with ioctls, passing a
string down to the loaded modules below it. So there is a bit of
president. Even if it is ugly :)
> > ...
> > +static struct page *find_page(struct dmfs_file *f, loff_t len, int fill)
>
> This is called under spinlock.
>
> > ...
> > + void *addr = (void *) __get_free_page(GFP_KERNEL);
>
> whoops.
Nice catch. I'm not sure that the find_page(), __io() and friends
functions are really needed at all.
Thanks for looking at this. I hope the dm authors can help explain
more.
greg k-h
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: David S. Miller @ 2002-12-13 5:23 UTC (permalink / raw)
To: matti.aarnio; +Cc: niv, alan, stefano.andreani.ap, linux-kernel, linux-net
In-Reply-To: <20021213033928.GK32122@mea-ext.zmailer.org>
From: Matti Aarnio <matti.aarnio@zmailer.org>
Date: Fri, 13 Dec 2002 05:39:28 +0200
On Thu, Dec 12, 2002 at 06:26:45PM -0800, Nivedita Singhvi wrote:
> Assuming you are on a local lan, your round trip
> times are going to be much less than 200 ms, and
> so using the TCP_RTO_MIN of 200ms ("The algorithm
> ensures that the rto cant go below that").
The RTO steps in only when there is a need to RETRANSMIT.
For that reason, it makes no sense to place its start
any shorter.
Actually, TCP_RTO_MIN cannot be made any smaller without
some serious thought.
The reason it is 200ms is due to the granularity of the BSD
TCP socket timers.
In short, the repercussions are not exactly well known, so it's
a research problem to fiddle here.
^ permalink raw reply
* (unknown)
From: David S. Miller @ 2002-12-13 5:24 UTC (permalink / raw)
To: p.Sawant; +Cc: linux-ide
In-Reply-To: <54670264D99F034EA23CBB7D7A45AE7E5EE0@zenmail1.ind.zensar.com>
From: "Paresh Sawant" <p.Sawant@zensar.com>
Date: Fri, 13 Dec 2002 10:32:07 +0530
unsubscribe linux-ide
You should't send unsubscribe requests to the mailing list,
what makes you think this will work?
Regardless, I've removed you manually.
^ permalink raw reply
* Re: [PATCH][COMPAT] consolidate sys32_new[lf]stat - architecture independent
From: David S. Miller @ 2002-12-13 5:32 UTC (permalink / raw)
To: sfr; +Cc: torvalds, linux-kernel, anton, ak, davidm, schwidefsky, ralf,
willy
In-Reply-To: <20021213153439.1f3e466e.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Dec 2002 15:34:39 +1100
Another in the COMPAT series. This build on the previous patches.
I'm totally fine with this stuff (and the sparc64 specific part), but
watch out, this patch removes the kernel/compat.c utimes stuff :-)
^ permalink raw reply
* [PATCH] signal.c: wrong rt signals comment, 2.4.20-pre11
From: Kristis Makris @ 2002-12-13 5:42 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 129 bytes --]
I'm sorry for being a little out of date.
I believe it's the RT signals that get queued. Someone please apply
against 2.5.x?
[-- Attachment #2: rt_signals_comment.patch --]
[-- Type: text/plain, Size: 416 bytes --]
--- linux/kernel/signal.c Sat Oct 19 11:58:48 2002
+++ linux-2.4.20-pre11.mod/kernel/signal.c Thu Dec 12 22:31:48 2002
@@ -237,7 +237,7 @@
kmem_cache_free(sigqueue_cachep,q);
atomic_dec(&nr_queued_signals);
- /* Non-RT signals can exist multiple times.. */
+ /* RT signals can exist multiple times.. */
if (sig >= SIGRTMIN) {
while ((q = *pp) != NULL) {
if (q->info.si_signo == sig)
^ permalink raw reply
* Re: massive compile failures w/ 2.5.51 on RH8.0
From: Randy.Dunlap @ 2002-12-13 5:42 UTC (permalink / raw)
To: Dave Jones; +Cc: Rod Van Meter, linux-kernel
In-Reply-To: <20021213002750.GB18156@suse.de>
On Fri, 13 Dec 2002, Dave Jones wrote:
| On Thu, Dec 12, 2002 at 04:06:59PM -0800, Rod Van Meter wrote:
|
| > At this point I've concluded that something in my setup is busted.
| > Surely this large a fraction of things don't currently fail to even
| > compile?
|
| This large a fraction of things don't currently compile.
| And don't call me Shirley. 8-)
|
| Seriously, you got unlucky, and seem to be hitting just about
| every broken driver/filesystem there is in 2.5 right now.
| If you take a look at bugzilla.kernel.org you'll see that
| most of the compile errors noted there are those that you've
| highlighted.
|
| Things like Intermezzo don't affect a large proportion of users,
| so remain broken for some time. The framebuffer changes in 2.5.51
| fixed up a whole bunch of problems that had been lingering for
| a while, but there's still a lot of drivers not converted over
| to the new API.
|
| Compile-time breakage is to be expected in 2.5.x. It's a hard-hat
| area. You may have more luck with 2.5-ac.
and some of these may have patches available for them on lkml.
I know that intermezzo does, from Peter Braam, with a small
follow-up by me, so it's fixable if you want it. Surely (Rod ;).
--
~Randy
^ permalink raw reply
* Re: Proposal: Alan Cox dev_printk() with advanced logging support
From: Greg KH @ 2002-12-13 5:47 UTC (permalink / raw)
To: Larry Kessler
Cc: linux-kernel mailing list, Alan Cox, Rusty Russell,
Richard J Moore, Werner Almesberger, James Keniston
In-Reply-To: <3DF93A71.15678A95@us.ibm.com>
On Thu, Dec 12, 2002 at 05:40:01PM -0800, Larry Kessler wrote:
>
> The version of dev_printk() being proposed here is essentially a
> generalized version of these macros, with a small change to Alan's
> version so that driver name and bus_id are prepended to the
> message...
>
> #define dev_printk(sev, dev, format, arg...) \
> printk(sev "%s %s: " format, (dev).driver->name, (dev).bus_id, ##arg)
>
> Then the logging macros in device.h can be re-written like this...
> #define dev_err(dev, format, arg...) \
> dev_printk(KERN_ERR, (dev), format, ## arg)
> ..and so on.
I'd gladly accept a patch to add dev_printk() like this right now, if
you want. But make sure you get the proper spacing to work properly on
older versions of gcc. Your above macros are incorrect with regards to
that :)
> What is _not_ addressed by this proposal are a number of other issues raised
> in the past, that still need addressing. For example...
>
> 1) (from Jeff Garzik) There's little or no stanardization of messages across
> different (but similar) devices.
>
> 2) (from Jeff Garzik and Greg KH) There's little or no guidance about what device
> specific details are most useful for Problem Determination, Sys Administration,
> etc.
>
> However, consistently identifying which device, plus state info from the device
> struct, plus other info. like source file, function name, and line number,
> provided with event logging, should certainly be useful in some cases.
> As the device struct continues to evolve, it will become more clear which
> device attributes are appropriate to log.
I really feel strongly that these questions need to be answered properly
before we start adding the larger event logging stuff to the main kernel
tree.
Oh yeah, patches to actually _use_ these dev_*() functions would also be
appreciated. It looks like only one very tiny driver subsystem has
started to use them. Patches from your group to change this would be
welcome.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit
From: Steffen Persvold @ 2002-12-13 5:53 UTC (permalink / raw)
To: James Cleverdon
Cc: Zwane Mwaikambo, Nakajima, Jun, Martin Bligh, John Stultz,
Linux Kernel
In-Reply-To: <200212121932.06196.jamesclv@us.ibm.com>
On Thu, 12 Dec 2002, James Cleverdon wrote:
> On Thursday 12 December 2002 07:26 pm, Zwane Mwaikambo wrote:
> > On Thu, 12 Dec 2002, Nakajima, Jun wrote:
> > > BTW, we are working on a xAPIC patch that supports more than 8 CPUs in a
> > > generic fashion (don't use hardcode OEM checking). We already tested it
> > > on two OEM systems with 16 CPUs.
> > > - It uses clustered mode. We don't want to use physical mode because it
> > > does not support lowest priority delivery mode.
> >
> > Wouldn't that only be for all including self? Or is the documentation
> > incorrect?
> >
> > Thanks,
> > Zwane
>
> I'm not sure I understand your question. Lowest Priority delivery mode only
> works with logical interrupts. (I've tried it with physical intrs. It fails
> miserably.) The "all including self" and "all excluding self" destination
> shorthands don't do lowest priority arbitration. They always deliver the
> interrupt to the CPUs mentioned in the shortand.
>
> Lowest priority delivery mode isn't _too_ useful in Linux yet. It would be
> nice to preferentially target idle CPUs with interrupts in real time. That
> means changing each CPU's Task Priority Register (TPR) to represent how busy
> it is. I've got some patches to do that, but haven't posted them as anything
> more than a RFC.
>
Hmm, I though the APIC routing patch found in the LSE project
(http://sourceforge.net/projects/lse/) did this already. Atleast I've
tested this patch on a couple of Dual E7500 Xeon boxes (kernel 2.4.20) and
it distributes interrupts nicely.
However with the patch enabled, the interrupt latency on for example the
Intel GbE 82544GC devices increased a fraction with this patch (a
microsecond or two).
Regards,
--
Steffen Persvold | Scali AS
mailto:sp@scali.com | http://www.scali.com
Tel: (+47) 2262 8950 | Olaf Helsets vei 6
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY
^ permalink raw reply
* [linux-lvm] New device-mapper patchset for 2.5.51
From: Joe Thornber @ 2002-12-13 5:50 UTC (permalink / raw)
To: Linux Mailing List, lvm-devel, linux-lvm
If anyone was experiencing problems with dm could they please try this
patchset and give me feedback.
Thanks,
- Joe
http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-3.tar.bz2
Changes
-------
Revision 1:
Four constants:
DM_DIR,
DM_MAX_TYPE_NAME,
DM_NAME_LEN,
DM_UUID_LEN
Were being declared in device-mapper.h, these are all specific to
the ioctl interface, so they've been moved to dm-ioctl.h. Nobody
in userland should ever include <linux/device-mapper.h> so remove
ifdef __KERNEL guards.
Revision 2:
An error value was not being checked correctly in open_dev().
[Kevin Corry]
Revision 3:
Return -ENOTBLK if lookup_device() finds the inode, but it
is not a block device. [Cristoph Hellwig]
Revision 4:
No need to validate the parameters if we are doing a
REMOVE_ALL command.
Revision 5:
check_device_area was comparing the bytes with sectors.
[Stefan Lauterbach]
Revision 6:
minor change for dm-strip.c. Tests for correct chunksize before it allocates
the stripe context. [Heinz Mauelshagen]
Revision 7:
There's a bug in the dm-stripe.c constructor failing top check if enough
destinations are handed in. [Heinz Mauelshagen]
Revision 8:
Give each device its own io mempool to avoid a potential
deadlock with stacked devices. [HM + EJT]
Revision 9:
queue_io() was checking the DMF_SUSPENDED flag rather than the new
DMF_BLOCK_IO flag. This meant suspend could deadlock under load.
Revision 10:
dm_suspend(): Stop holding the read lock around the while loop that
waits for pending io to complete.
Revision 11:
Add a blk_run_queues() call to encourage pending io to flush
when we're doing a dm_suspend().
Revision 12:
dec_pending(): only bother spin locking if io->error is going to be
updated. [Kevin Corry]
Revision 13:
md->pending was being incremented for each clone rather than just
once. [Kevin Corry]
Revision 14:
Some fields in the duplicated bio weren't being set up properly in
__split_page(). [Kevin Corry]
Revision 15:
Remove some paranoia in highmem.c, need to check this with Jens Axboe.
Revision 16:
Remove verbose debug message 'Splitting page'.
Revision 17:
o If there's an error you still need to call bio_endio with bio->bi_size
as the 'done' param.
o Simplify clone_endio.
[Kevin Corry]
Revision 18:
The block layer does not honour bio->bi_size when issuing io, instead
it performs io to the complete bvecs. This means we have to change
the bio splitting code slightly.
Given a bio we repeatedly apply one of the following three operations
until there is no more io left in the bio:
1) The remaining io does not cross an io/target boundary, so just
create a clone and issue all of the io.
2) There are some bvecs at the start of the bio that are not split by
a target boundary. Create a clone for these bvecs only.
3) The first bvec needs splitting, use bio_alloc() to create *two*
bios, one for the first half of the bvec, the other for the second
half. A bvec can never contain more than one boundary.
Revision 19:
For large bios it was possible to look up the wrong target. Bug
introduced by the recent splitting changes.
Revision 20:
The linear target was getting the start sector wrong when doing a
dm_get_device(). [Kevin Corry]
^ permalink raw reply
* Re: non-standard FTP ports and connection tracking (redux)
From: Joel Newkirk @ 2002-12-13 6:09 UTC (permalink / raw)
To: Alexandros Papadopoulos; +Cc: netfilter
In-Reply-To: <200212101118.53239.apapadop@cmu.edu>
On Tuesday 10 December 2002 11:18 am, Alexandros Papadopoulos wrote:
> The default behavior is DROP for all chains, so if these ones don't
> allow it, then it is blocked. I thought these ones were sufficient.
> I'm attaching the complete ruleset I'm using.
>
> > > I'd bet that the problem is that the SYN request sent from the
> > > client to my server gets dropped, though. Seems like a
> > > conntrack/INPUT thing.
> >
> > I'd setup logging rules to see where and why the connection gets
> > blocked.
This is always useful. Almost every time something unexpected is
happening you can look at the logging from an attempted connection or
two and quickly see where the packet appears, and where it doesn't. Set
a log rule as the first in each chain for just long enough to try a
connection, disable the logging, and check the logs. Just trace the
appearance of the packets, and compare to what SHOULD happen. IE: if it
shows up in PREROUTING and INPUT, then response in OUTPUT but not
POSTROUTING, then it's being blocked in OUTPUT. The log can also turn
up instances where the addresses or port numbers are not what you
expected when you built the rules.
> I've monitored the packets with Ethereal and seen that the problem is
> the one mentioned -- the SYN packet from the client that tries to open
> the data connection (when in passive mode) never makes it through the
> firewall.
>
> The question is, why doesn't connection tracking pick this up and
> allow the packet to go through? (since it's a RELATED connection to a
> preexisting FTP session)
Two questions.
1 - What is this supposed to achieve?
#### CHAIN FORWARD ####
#######################
#/sbin/iptables -t nat -A POSTROUTING -p tcp --dport 55555 -j REDIRECT
--to-port 80
REDIRECT isn't a valid target in nat-POSTROUTING. If you are trying to
redirect anything outbound from the local box with destport 55555 and
loop it back to destport 80 on the local box, this should be nat-OUTPUT.
I can't see anything else you would be trying to do with this.
2 - Are you sure that FTP and HTTP replies will have source ports of 1024
or higher?
## Allow outgoing FTP (data) + HTTP replies
/sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state
--state ESTABLISHED,RELATED -j ACCEPT
Try this with no --sport match at all and see what happens. be careful
that you are not TOO specific in the matches you require.
j
^ permalink raw reply
* Re: Is the preemptive kernel patch unsafe for 8xx/PPC?
From: Eugene Surovegin @ 2002-12-13 6:09 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <001901c2a21d$f3f4e760$0200a8c0@jockeXP>
Joakim,
At 12:35 PM 12/12/2002, you wrote:
>Was that the 2.4.19-2 patch? What were the bugs and have you fixed them?
I had the following issues with 2.4.19-2 (2.4.20-1 is identical in this
regard):
1) arch/ppc/kernel.entry.S
diff -urN linux-2.4.20/arch/ppc/kernel/entry.S linux/arch/ppc/kernel/entry.S
--- linux-2.4.20/arch/ppc/kernel/entry.S 2002-11-28
18:53:11.000000000 -0500
+++ linux/arch/ppc/kernel/entry.S 2002-12-11 02:34:47.000000000 -0500
@@ -278,6 +278,41 @@
*/
cmpi 0,r3,0
beq restore
+#ifdef CONFIG_PREEMPT
+ lwz r3,PREEMPT_COUNT(r2)
+ cmpi 0,r3,1
+ bge ret_from_except
+ lwz r5,_MSR(r1)
+ andi. r5,r5,MSR_PR
+ bne do_signal_ret
<rest of the diff is skipped>
I had to change the last command to "bne ret_from_except".
I checked MontaVista tree, and they have "ret_from_except" there also.
Without this change trivial code:
while (true) ;
locked the box completely.
2) include/asm-ppc/pgalloc.h There are curly brackets missing in
get_pgd_fast()
3) to support 440GP you have to modify arc/ppc/kernel/irc.c:preempt_intercept:
#if !defined(CONFIG_4xx) || defined(CONFIG_440)
case 0x900:
#else
case 0x1000:
#endif
With these changes (an maybe some others I forgot to mention here :),
I have pretty stable preemptable kernel (2.4.19, PPC440GP & 405GP, also
with rtsched patch by George Anzinger)
Thanks,
Eugene Surovegin <mailto:ebs@innocent.com>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH][COMPAT] consolidate sys32_new[lf]stat - architecture independent
From: Stephen Rothwell @ 2002-12-13 6:18 UTC (permalink / raw)
To: David S. Miller
Cc: torvalds, linux-kernel, anton, ak, davidm, schwidefsky, ralf,
willy
In-Reply-To: <20021212.213231.63672402.davem@redhat.com>
On Thu, 12 Dec 2002 21:32:31 -0800 (PST) "David S. Miller" <davem@redhat.com> wrote:
>
> I'm totally fine with this stuff (and the sparc64 specific part), but
> watch out, this patch removes the kernel/compat.c utimes stuff :-)
And adds it into fs/compat.c where it should have been in the first place ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* kernel: matrox fb - missing files, doesn't compile
From: Ariel @ 2002-12-13 6:13 UTC (permalink / raw)
To: vandrove; +Cc: linux-fbdev-devel
Kernel 2.5.51.
I tried copying the fbcon*.h files from 2.2.19 kernel, but that didn't
help much.
Clip from .config:
# Graphics support
CONFIG_FB=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G100A=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=y
CONFIG_FB_MATROX_MAVEN=y
(I also have I2C on.)
Output of make:
make -f scripts/Makefile.build obj=drivers/video/matrox
gcc -Wp,-MD,drivers/video/matrox/.matroxfb_base.o.d -D__KERNEL__
-Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -Iarch/i386/mach-generic -fomit-frame-pointer -nostdinc
-iwithprefix include -DKBUILD_BASENAME=matroxfb_base
-DKBUILD_MODNAME=matroxfb_base -DEXPORT_SYMTAB -c -o
drivers/video/matrox/matroxfb_base.o drivers/video/matrox/matroxfb_base.c
In file included from drivers/video/matrox/matroxfb_base.c:105:
drivers/video/matrox/matroxfb_base.h:52: video/fbcon.h: No such file or
directory
drivers/video/matrox/matroxfb_base.h:53: video/fbcon-cfb4.h: No such file
or directory
drivers/video/matrox/matroxfb_base.h:54: video/fbcon-cfb8.h: No such file
or directory
drivers/video/matrox/matroxfb_base.h:55: video/fbcon-cfb16.h: No such file
or directory
drivers/video/matrox/matroxfb_base.h:56: video/fbcon-cfb24.h: No such file
or directory
drivers/video/matrox/matroxfb_base.h:57: video/fbcon-cfb32.h: No such file
or directory
In file included from drivers/video/matrox/matroxfb_base.c:105:
drivers/video/matrox/matroxfb_base.h:341: warning: `struct display'
declared inside parameter list
drivers/video/matrox/matroxfb_base.h:341: warning: its scope is only this
definition or declaration, which is probably not what you want.
drivers/video/matrox/matroxfb_base.h:342: warning: `struct display'
declared inside parameter list
drivers/video/matrox/matroxfb_base.h:558: field `dispsw' has incomplete
type
drivers/video/matrox/matroxfb_base.c:148: warning: braces around scalar
initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization
for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in
scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization
for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in
scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization
for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in
scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization
for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in
scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization
for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in
scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization
for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c: In function `my_install_cmap':
drivers/video/matrox/matroxfb_base.c:158: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c: In function `matrox_pan_var':
drivers/video/matrox/matroxfb_base.c:186: warning: implicit declaration of
function `fontheight'
drivers/video/matrox/matroxfb_base.c:186: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:186: warning: implicit declaration of
function `fontwidth'
drivers/video/matrox/matroxfb_base.c:169: warning: `pos' might be used
uninitialized in this function
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_pan_display':
drivers/video/matrox/matroxfb_base.c:279: `fb_display' undeclared (first
use in this function)
drivers/video/matrox/matroxfb_base.c:279: (Each undeclared identifier is
reported only once
drivers/video/matrox/matroxfb_base.c:279: for each function it appears
in.)
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_updatevar':
drivers/video/matrox/matroxfb_base.c:303: `fb_display' undeclared (first
use in this function)
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_set_var':
drivers/video/matrox/matroxfb_base.c:688: `fb_display' undeclared (first
use in this function)
drivers/video/matrox/matroxfb_base.c:690: structure has no member named
`disp'
drivers/video/matrox/matroxfb_base.c:700: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:701: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:702: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:703: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:704: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:705: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:706: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:707: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:711: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:721: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:725: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:728: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:729: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:735: structure has no member named
`changevar'
drivers/video/matrox/matroxfb_base.c:736: structure has no member named
`changevar'
drivers/video/matrox/matroxfb_base.c:802: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:678: warning: `display' might be used
uninitialized in this function
drivers/video/matrox/matroxfb_base.c:738: warning: `pos' might be used
uninitialized in this function
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_get_cmap':
drivers/video/matrox/matroxfb_base.c:866: structure has no member named
`disp'
drivers/video/matrox/matroxfb_base.c:867: `fb_display' undeclared (first
use in this function)
drivers/video/matrox/matroxfb_base.c:876: warning: implicit declaration of
function `fb_get_cmap'
drivers/video/matrox/matroxfb_base.c:877: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:878: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:880: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_set_cmap':
drivers/video/matrox/matroxfb_base.c:890: structure has no member named
`disp'
drivers/video/matrox/matroxfb_base.c:890: `fb_display' undeclared (first
use in this function)
drivers/video/matrox/matroxfb_base.c:899: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:900: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:903: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:910: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_ioctl':
drivers/video/matrox/matroxfb_base.c:1009: structure has no member named
`switch_con'
drivers/video/matrox/matroxfb_base.c: At top level:
drivers/video/matrox/matroxfb_base.c:1188: unknown field `fb_set_var'
specified in initializer
drivers/video/matrox/matroxfb_base.c:1188: warning: initialization from
incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1189: unknown field `fb_get_cmap'
specified in initializer
drivers/video/matrox/matroxfb_base.c:1189: warning: initialization from
incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1190: unknown field `fb_set_cmap'
specified in initializer
drivers/video/matrox/matroxfb_base.c:1190: warning: initialization from
incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1192: warning: initialization from
incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1194: warning: initialization from
incompatible pointer type
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_switch':
drivers/video/matrox/matroxfb_base.c:1207: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:1222: structure has no member named
`disp'
drivers/video/matrox/matroxfb_base.c:1224: `fb_display' undeclared (first
use in this function)
drivers/video/matrox/matroxfb_base.c:1226: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:1235: derefe member named `changevar'
drivers/video/matrox/matroxfb_base.c:1757: structure has no member named
`disp'
drivers/video/matrox/matroxfb_base.c:1758: structure has no member named
`switch_con'
drivers/video/matrox/matroxfb_base.c:1759: structure has no member named
`updatevar'
drivers/video/matrox/matroxfb_base.c:1875: structure has no member named
`modename'
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_probe':
drivers/video/matrox/matroxfb_base.c:1986: storage size of `global_disp'
isn't known
drivers/video/matrox/matroxfb_base.c:2028: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:2028: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:2028: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:2028: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:2028: dereferencing pointer to
incomplete type
drivers/video/matrox/matroxfb_base.c:2028: dereferencing pointer to
incomplete type
driver might be used uninitialized in this function
make[3]: *** [drivers/video/matrox/matroxfb_base.o] Error 1
make[2]: *** [drivers/video/matrox] Error 2
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2
root@blueberry:/usr/src/linux-2.5.51#
-Ariel
-------------------------------------------------------
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: R: Kernel bug handling TCP_RTO_MAX?
From: Nivedita Singhvi @ 2002-12-13 6:26 UTC (permalink / raw)
To: Matti Aarnio, Alan Cox, Andreani Stefano, David S. Miller,
Linux Kernel Mailing List, linux-net
In-Reply-To: <3DF965E4.95DEA1F9@us.ibm.com>
Nivedita Singhvi wrote:
> our default init rto is 300, so currently we're going to timeout
> on anything thats a 100ms over the min of 200. that is far
> less conservative than setting an rto of 200 when your round
> trip time is a thousand or 10,000 times less..does that make sense?
Doh! init rto is NOT 300ms, its 3 seconds. That minor blooper
shreds my comparison argument a tad :)..but Dave's point renders
that moot, in any case..
"David S. Miller" wrote:
> Actually, TCP_RTO_MIN cannot be made any smaller without
> some serious thought.
>
> The reason it is 200ms is due to the granularity of the BSD
> TCP socket timers.
>
> In short, the repercussions are not exactly well known, so it's
> a research problem to fiddle here.
Ack.
Sometime in the not too distant future, the next generation of
infrastructure will require this to be reworked :).
thanks,
Nivedita
^ permalink raw reply
* interest to be in the mailing list
From: Chun-Hong Tham @ 2002-12-13 6:30 UTC (permalink / raw)
To: linux-c-programming
hi,
i'm keen to learn more. hope you could put me in the
distribution list. thanks a million.
regards,
thamch
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).
From: Antonino Daplas @ 2002-12-13 9:34 UTC (permalink / raw)
To: James Simmons; +Cc: Miles Lane, Linux Fbdev development list
In-Reply-To: <Pine.LNX.4.44.0212130508050.10929-100000@phoenix.infradead.org>
On Fri, 2002-12-13 at 10:09, James Simmons wrote:
>
> > Can you test the attached patch (rivafb1.diff)? It fixes some things:
>
> I tested the patch. The colors are still messed up :-( I'm running at 8
> bpp mode. I applied the patch since it fixed some important things.
> I also add support and more functionality. I still have some to go.
>
I'm confused too :-(. If I'm going to expect color problems, it's not
at bpp8 since you don't really do anything except write to the DAC. And
the fact that the driver works perfectly for the Riva128 (nvidia's first
chipset) makes me wonder even more. Currently, I'm running everything
with the riva128, directfb, xfbdev, even the xgamma utility works,
flawlessly.
The only thing I can think of that we're doing differently from the 2.4
driver is the save_vga() part in rivafb_open. Perhaps touching the vga
registers somehow confuses the hardware. Unlikely, but maybe worth a
try.
How extensive is the color problem? Does it just affect the logo, or
everything? Also, is the color problem present in both hardware and
software mode (just do fbset -accel true/false to find out)? Is the
vertical mirroring as reported by Miles still present? How about bpp16
or bpp32?
How I would love to debug that, but I don't have the hardware :-(
Tony
-------------------------------------------------------
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: Why does C3 CPU downgrade in kernel 2.4.20?
From: Joseph @ 2002-12-13 6:55 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021212133339.GE1145@suse.de>
>>On Thu, Dec 12, 2002 at 05:17:29PM +0800, Joseph wrote:
>> Thanks for all response. :)
>> I think I know more why it downgrades.
>> But one more curious question.
>> In the file, arch/i386/Makefile, under kernel 2.5.51.
>> I found the C3 alignments , $(call check_gcc, -march=c3,-march=i486).
>> Does the C3 CPU type be included in gcc compile option??
>> I've downloaded the latest gcc 3.2.1 version.
>> But I don't find the c3 options in the file gcc/config/i396/i386.c,
i386.h
>> or etc.
>Not in a currently released gcc. CVS HEAD supports it, as will 3.3
>Dave
I've checked the gcc CVS. But it seems to use i486 pluse MMX and 3DNOW
instructions.
* config.gcc: Treat winchip_c6-*|winchip2-*|c3-* as pentium-mmx.
* config/i386/i386.c (processor_alias_table): Add winchip-c6, winchip2 and
c3.
* doc/invoke.texi: Mention new aliases.
** {"c3", PROCESSOR_I486, PTA_MMX | PTA_3DNOW}, **
Is there any plan to optimize for C3 CPU in future gcc released version?
BR,
Joseph
-----------------------------------------------------------------
< 每天都 Yahoo!奇摩 > www.yahoo.com.tw
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: David Stevens @ 2002-12-13 6:55 UTC (permalink / raw)
To: David S. Miller
Cc: matti.aarnio, niv, alan, stefano.andreani.ap, linux-kernel,
linux-net
I believe the very large BSD number was based on the large
granularity of the timer (500ms for slowtimeout), designed for use on a VAX
780. The PC on my desk is 3500 times faster than a VAX 780, and you can
send a lot of data on Gigabit Ethernet instead of sitting on your hands for
an enormous min timeout on modern hardware. Switched gigabit isn't exactly
the same kind of environment as shared 10 Mbps (or 2 Mbps) when that stuff
went in, but the min timeouts are the same.
I think the exponential back-off should handle most issues for
underestimated timers, and the min RTO should be the timer granularity.
Variability in that is already accounted for by the RTT estimator.
I certainly agree it needs careful investigating, but it's been a pet
peeve of mine for years on BSD systems that it forced an arbitrary minimum
that had no accounting for hardware differences over the last 20 years.
+-DLS
"David S. Miller" <davem@redhat.com>@vger.kernel.org on 12/12/2002 09:23:35
PM
Sent by: linux-net-owner@vger.kernel.org
To: matti.aarnio@zmailer.org
cc: niv@us.ltcfwd.linux.ibm.com, alan@lxorguk.ukuu.org.uk,
stefano.andreani.ap@h3g.it, linux-kernel@vger.kernel.org,
linux-net@vger.kernel.org
Subject: Re: R: Kernel bug handling TCP_RTO_MAX?
From: Matti Aarnio <matti.aarnio@zmailer.org>
Date: Fri, 13 Dec 2002 05:39:28 +0200
On Thu, Dec 12, 2002 at 06:26:45PM -0800, Nivedita Singhvi wrote:
> Assuming you are on a local lan, your round trip
> times are going to be much less than 200 ms, and
> so using the TCP_RTO_MIN of 200ms ("The algorithm
> ensures that the rto cant go below that").
The RTO steps in only when there is a need to RETRANSMIT.
For that reason, it makes no sense to place its start
any shorter.
Actually, TCP_RTO_MIN cannot be made any smaller without
some serious thought.
The reason it is 200ms is due to the granularity of the BSD
TCP socket timers.
In short, the repercussions are not exactly well known, so it's
a research problem to fiddle here.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" 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: grub and 2.5.50
From: Matt Young @ 2002-12-13 6:58 UTC (permalink / raw)
To: Alex Tomas, Stefan Reinauer; +Cc: Linux Kernel Mailing List
In-Reply-To: <m3wumfz8ne.fsf@lexa.home.net>
Got things going by doing that trick, good tip,
On Thursday 12 December 2002 05:09, Alex Tomas wrote:
> >>>>> Stefan Reinauer (SR) writes:
>
> SR> * Matt Young <wz6b@arrl.net> [021210 01:40]:
> >> These grub commands work with SUSE 2.4.19-4GB:
> >>
> >> kernel (hd0,0)/bzImage root=/dev/hda3 vga=791 initrd
> >> (hd0,0)/initrd
> >>
> >> But with 2.5.50 the kernel panics after Freeing the initrd memory
> >> with "Unable te mount root FS, please correct the root= cammand
> >> line"
> >>
> >> I have compiled with the required file systems
> >> (EXT2,EXT3,REISERFS).
>
> SR> Did you also compile in support for the root device itself
> SR> (i.e. ide or scsi driver). These are loaded via the initrd
> SR> normally on SuSE, which will not work, if you did not install
> SR> newer modutils..
>
> First of all, 2.5.10 has sysfs-related bug. try to replace root=/dev/hda3
> by root=303
>
> -
> 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/
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: David S. Miller @ 2002-12-13 6:59 UTC (permalink / raw)
To: dlstevens
Cc: matti.aarnio, niv, alan, stefano.andreani.ap, linux-kernel,
linux-net
In-Reply-To: <OF38D59D15.E0619D28-ON88256C8E.0023807F@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Thu, 12 Dec 2002 23:55:35 -0700
I believe the very large BSD number was based on the large
granularity of the timer (500ms for slowtimeout), designed for use on a VAX
780. The PC on my desk is 3500 times faster than a VAX 780, and you can
send a lot of data on Gigabit Ethernet instead of sitting on your hands for
an enormous min timeout on modern hardware. Switched gigabit isn't exactly
the same kind of environment as shared 10 Mbps (or 2 Mbps) when that stuff
went in, but the min timeouts are the same.
This is well understood, the problem is that BSD's coarse timers are
going to cause all sorts of problems when a Linux stack with a reduced
MIN RTO talks to it.
Consider also, delayed ACKs and possible false retransmits this could
induce with a smaller MIN RTO.
^ permalink raw reply
* Re: problems with ALSA
From: pa3gcu @ 2002-12-13 7:00 UTC (permalink / raw)
To: r4mz3z, linux-newbie
In-Reply-To: <200212110750.08044.r4mz3z@yahoo.es>
On Wednesday 11 December 2002 07:49, r4mz3z wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi friends...
> I have a VIA sound card and I've supossed ALSA drivers can give sound...
> I follow the instructions but when (been root) run modprobe receive an
> error... just like this:
> - -------------------------------------------------------------
> [root@localhost root]# modprobe snd-via82xx
> /lib/modules/.../snd.o: unresolved symbol __get_free_pages_Rsmp_4784e424
> /lib/modules/.../snd.o: unresolved symbol try_inc_mod_count_Rsmp_e6105b23
> /lib/modules/2.4.18-3/kernel/drivers/sound/snd.o: insmod snd-via82xx failed
> [root@localhost root]#
> - -------------------------------------------------------------
> The path complete is: /lib/modules/2.4.18-3/kernel/drivers/sound/
> I'm using RedHat 7.3.
>
Nowhere do you mention which version of alsa you are using, you need at least
0.9.0rc5 which can be obtained at;
http://www.alsa-project.org/
I had to use the above version to get my via8233 Southbridge working.
--
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/
-
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
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.