* Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).
From: Miles Lane @ 2002-12-11 6:10 UTC (permalink / raw)
To: James Simmons; +Cc: linux-fbdev-devel
In-Reply-To: <Pine.LNX.4.33.0212102136050.2617-100000@maxwell.earthlink.net>
James, I appreciate all your hard work. I hope my bug report
isn't too upsetting for you. I think you are making great progress.
It is also a shame that so much of the driver porting has fallen
on your shoulders. If I were a programmer. I'd help, but my skills
are in software testing, for the most part.
All the best,
Miles
James Simmons wrote:
>>I have tried getting rivafb to work in 2.5.51. It is much better
>>than before (thanks!). It compiles and sorta works.
>
>
> Ug. Now that several drivers compile now I get bug reports :-( I'm getting
> alot of positive feedback as well as one negative source.
>
>
>>Here are the problems:
>>
>>When I run "fbset -a 640x480", I get display that fills
>>the screen and looks okay, but most of the characters are
>>flipped along the vertical axis, so they are backwards, so that:
>>
>>+---- ----+
>>| |
>>+--- becomes ---+
>>| |
>>| |
>
>
> Okay. That is weird. I have this card so I will give it a try.
>
>
>>Also, when I boot, the penguin logo looks like it is being rendered
>>in about five colors.
>
>
> Yipes. Imageblit sounds broken.
>
>
>>In addition, the text is black, except for
>>the white underscore cursor, so all I can see is the cursor.
>
>
> I noticed this. The color palette is for some reason messed up.
>
>
>>When the gpm gets loaded, the mouse pointer, instead of showing
>>a white rectangle that, when it passes over a character, shows that
>>character in reverse-video, shows a colored cursor that always
>>contains some character. The character shown in the mouse cursor
>>changes when it passes over text in the window, but it never shows
>>the character it is passing over.
>
>
> Same things. Color palette is messed up.
>
>
>>Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows
>>a usable console window, but it is embedded in the larger high
>>resolution display, like this:
>>
>> +---------+----------------+
>> | | |
>> | | |
>> | | |
>> +---------+ |
>> | |
>> | |
>> | |
>> | |
>> | |
>> +--------------------------+
>>
>>The area outside of the 640x480 boundary is filled with colored
>>junk (no characters).
>>
>>Any ideas?
>
>
> Yeap. I migrated changing the console from /dev/fb to actually using the
> tty layer. I haven't merged those changes yet but you will be able to do a
>
> stty -f /dev/ttyX 80 col 50 row
>
> and change the video mode.
>
> So I didn't plan to push so soon but I kept getting emails about various
> drivers being broken. So I did this push to make more drivers work.
> Unfortuenly I sent a watered down fbcon system.
>
>
>
>
>
>
-------------------------------------------------------
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: vmalloc
From: Joseph D. Wagner @ 2002-12-11 6:16 UTC (permalink / raw)
To: 'Arjan van de Ven', imran.badr; +Cc: 'Linux-kernel'
In-Reply-To: <1039554761.10002.31.camel@laptop.fenrus.com>
>> Is there any limitation on the amount of
>> memory that can be allocated by using vmalloc
>> ( like 128KB for kmalloc) ?
> for x86 you shouldn't count on being to get more
> than 64Mb of vmalloc memory (even though most
> machines go upto 128Mb at least)
According to the specifications, vmalloc is limited only by the amount of
physical memory on your machine. However, Arjan VanDeVen has a point.
Other process are already using physical memory (like the kernel process),
and those process count against the physical memory available.
TIP: It's always nice to leave at least 20% of the physical memory free for
other critical processes, especially those that can't be swapped out.
Joseph Wagner
^ permalink raw reply
* Re: portfw on iptables 2.4 kernel problem.
From: louie miranda @ 2002-12-11 6:08 UTC (permalink / raw)
To: netfilter
In-Reply-To: <Pine.LNX.4.33.0212101216060.9625-100000@blackhole.kfki.hu>
Hi, thanks for all your replies, etc. But my problem is not yet solved. I
dont know why?!
Can someone give me how did they did it?
--
thanks,
louie miranda
----- Original Message -----
From: "Jozsef Kadlecsik" <kadlec@blackhole.kfki.hu>
To: "Raymond Leach" <raymondl@knowledgefactory.co.za>
Cc: <rsterenborg@xs4all.nl>; "'Paulo Andre'" <pandre@darkstar.nom.za>;
"'louie miranda'" <lmiranda@chikka.com>; "'netfilter'"
<netfilter@lists.netfilter.org>
Sent: Tuesday, December 10, 2002 7:22 PM
Subject: RE: portfw on iptables 2.4 kernel problem.
> On 10 Dec 2002, Raymond Leach wrote:
>
> > Yes, you do. Port 20 (and/or any other) connections after the control
> > connection are not 'RELATED, ESTABLISHED' to the control connection.
> > They are new connections either from the client to the server or vice
> > versa. You therefore need seperate rules for them.
>
> If we are speaking about the data channels of the supported protocols
> (FTP, IRC and all the other protocols from p-o-m), then this is absolutely
> false.
>
> > Remember connection tracking happens at a pakcet level, i.e all states
> > relate to packets of a connection, not per protocol.
>
> In the case of the supported protocols with additional channels, again,
> untrue. Please do no spread false info! Why would then the RELATED state
> exist?
>
> > > However, I'm not sure if it's better to split them up into 2 rules :
> > > iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> > > NEW -j ACCEPT
> > > iptables -A FORWARD -i eth0 -o eth1 -m state --state
ESTABLISHED,RELATED
> > > -j ACCEPT
>
> Because the destination port of the data channels cannot be port 21,
> therefore you must use two rules. And because you specify the
> incoming/outgoing interfaces, you need a third rule for the reply packets
> as well.
>
> Regards,
> Jozsef
> -
> E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> Address : KFKI Research Institute for Particle and Nuclear Physics
> H-1525 Budapest 114, POB. 49, Hungary
>
>
>
^ permalink raw reply
* RAV antivirus?
From: Manoj Sharma @ 2002-12-11 6:07 UTC (permalink / raw)
To: linux-admin
Has anyone used RAV antivirus for the mailservers (Sendmail, RedHat Linux)?
Do you recommend this Anti Virus for Sendmail?
Thanks
-Manoj
^ permalink raw reply
* MySQL or postgreSQL which is the best?
From: lisa leblanc @ 2002-12-11 6:00 UTC (permalink / raw)
To: linux-admin
I have to choose between these databases and I do not know which is the
best. What do you think?
Lisa
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
^ permalink raw reply
* Oops 2.4.20-ac1 & 2.4.21-pre1 ide-scsi
From: Alexander Grishin @ 2002-12-11 6:07 UTC (permalink / raw)
To: linux-kernel
The next commands:
modprobe ide-scsi
rmmod ide-scsi
mount -t iso9660 /dev/hdc /mnt
Oops....
Dec 11 08:58:28 gri kernel: scsi0 : SCSI host adapter emulation for IDE ATAPI
devices
Dec 11 08:58:28 gri kernel: Vendor: _NEC Model: NR-7900A Rev:
1.23
Dec 11 08:58:28 gri kernel: Type: CD-ROM ANSI
SCSI revision: 02
Dec 11 08:58:37 gri kernel: scsi : 0 hosts left.
Dec 11 08:58:37 gri kernel: idescsi_cleanup: hdc: failed to unregister!
Dec 11 08:58:37 gri kernel: hdc: usage 0, busy 0, driver d8932700, Dbusy 1
Dec 11 08:58:37 gri kernel: hdc: exit_idescsi_module() called while still busy
Dec 11 08:58:55 gri kernel: Unable to handle kernel paging request at virtual
address 24448b61
Dec 11 08:58:55 gri kernel: printing eip:
Dec 11 08:58:55 gri kernel: 24448b61
Dec 11 08:58:55 gri kernel: *pde = 00000000
Dec 11 08:58:55 gri kernel: Oops: 0000
Dec 11 08:58:55 gri kernel: CPU: 0
Dec 11 08:58:55 gri kernel: EIP: 0010:[<24448b61>] Not tainted
Dec 11 08:58:55 gri kernel: EFLAGS: 00010246
Dec 11 08:58:55 gri kernel: eax: d674be3c ebx: c02be13c ecx: c02c02ec
edx: d8932700
Dec 11 08:58:55 gri kernel: esi: c14461c0 edi: d654c3c0 ebp: 00001600
esp: d674bd80
Dec 11 08:58:55 gri kernel: ds: 0018 es: 0018 ss: 0018
Dec 11 08:58:55 gri kernel: Process mount (pid: 379, stackpage=d674b000)
Dec 11 08:58:55 gri kernel: Stack: c01acfcd d654c3c0 d674be3c c02be13c
c14461c0 c14461c0 c14461dc c013ce24
Dec 11 08:58:55 gri kernel: d654c3c0 d674be3c 00000000 c14461c0
fffffff3 d674be38 00000003 c013cec7
Dec 11 08:58:55 gri kernel: c14461c0 d654c3c0 d674be3c 00000000
00000000 d654c3c0 00000000 00000000
Dec 11 08:58:55 gri kernel: Call Trace: [<c01acfcd>] [<c013ce24>]
[<c013cec7>] [<c013c996>] [<c013b959>]
Dec 11 08:58:55 gri kernel: [<c014cc5e>] [<d8934944>] [<c013bd5c>]
[<d8934944>] [<c014ddc3>] [<c014e0c5>]
Dec 11 08:58:55 gri kernel: [<c014df19>] [<c014e4f1>] [<c010733f>]
Dec 11 08:58:55 gri kernel:
Dec 11 08:58:55 gri kernel: Code: Bad EIP value.
^ permalink raw reply
* [PATCH] fix trivial drivers/char/agp/generic.c compile warning
From: Robert Love @ 2002-12-11 6:07 UTC (permalink / raw)
To: davej; +Cc: linux-kernel
In 2.5.51, I get:
drivers/char/agp/generic.c: In function `agp_generic_create_gatt_table':
drivers/char/agp/generic.c:472: warning: assignment from incompatible pointer type
gatt_table_real used to be 'u32' but now it is 'unsigned long'... and a
typecast was not updated.
Trivial patch applied, against 2.5.51.
Robert Love
drivers/char/agp/generic.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -urN linux-2.5.51/drivers/char/agp/generic.c linux/drivers/char/agp/generic.c
--- linux-2.5.51/drivers/char/agp/generic.c 2002-12-10 17:45:01.000000000 -0500
+++ linux/drivers/char/agp/generic.c 2002-12-11 01:00:28.000000000 -0500
@@ -469,8 +469,8 @@
for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
SetPageReserved(page);
- agp_bridge.gatt_table_real = (u32 *) table;
- agp_gatt_table = (void *)table;
+ agp_bridge.gatt_table_real = (unsigned long *) table;
+ agp_gatt_table = (void *)table;
CACHE_FLUSH();
agp_bridge.gatt_table = ioremap_nocache(virt_to_phys(table),
(PAGE_SIZE * (1 << page_order)));
^ permalink raw reply
* Re: [TRIVIAL PATCH] FBDEV: Small impact patch for fbdev
From: James Simmons @ 2002-12-11 5:59 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Linux Fbdev development list, Linux Kernel Mailing List
In-Reply-To: <1039558622.1054.32.camel@localhost.localdomain>
> Here's a diff to correct several small things that escaped through the
> cracks.
Ug. Now that a wider test base is being done and more drivers actually
compile we are going to see more cracks.
> 1. The YNOMOVE scrollmode for non-accelerated drivers is just very slow
> because of a lot of block moves (leads to slow and jerky scrolling in
> vesafb with ypanning enabled). Depending on var->accel_flags, set the
> scrollmode to either YREDRAW or YNOMOVE. For drivers with hardware
> acceleration, set var->accel_flags to nonzero for max speed.
Thanks. I have had several emails complementing the speed improvements.
Another speed boost will be a plus.
> 2. fb_pan_display() always returns an error. User apps will complain.
Fixed. Actually I used the following code.
int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
{
int xoffset = var->xoffset;
int yoffset = var->yoffset;
int err;
if (xoffset < 0 || yoffset < 0 || info->fbops->fb_pan_display ||
xoffset + info->var.xres > info->var.xres_virtual ||
yoffset + info->var.yres > info->var.yres_virtual)
return -EINVAL;
if ((err = info->fbops->fb_pan_display(var, info)))
return err;
info->var.xoffset = var->xoffset;
info->var.yoffset = var->yoffset;
if (var->vmode & FB_VMODE_YWRAP)
instead. The reason is I didn't like the idea of xoffset and yoffset being
changed even if the hardware panning function failed. Comments?
> 3. case FBIO_GETCMAP in fb_ioctl does not return immediately. User
> apps will complain.
Fixed.
> 4. vgastate.c is not saving the correct blocks.
Fixed.
> 5. logo drawing for monochrome displays is just incorrect.(alterations
> were done by eyeballing only, no hardware for testing).
Will test on hgafb driver.
^ permalink raw reply
* [PATCH] AGP support VIA VT8633
From: Nathaniel Russell @ 2002-12-11 6:06 UTC (permalink / raw)
To: marcelo; +Cc: linux-kernel, alan
In-Reply-To: <Pine.LNX.4.44.0212110016470.2208-200000@reddog.example.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 351 bytes --]
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
THIS IS A REVISED PATCH
[-- Attachment #2: Via VT8633 Support --]
[-- Type: TEXT/PLAIN, Size: 1979 bytes --]
diff -urN linux-agp/drivers/char/drm-4.0/agpsupport.c~ linux/drivers/char/drm-4.0/agpsupport.c
--- linux-agp/drivers/char/drm-4.0/agpsupport.c~ 2002-12-03 21:07:08.000000000 -0500
+++ linux/drivers/char/drm-4.0/agpsupport.c 2002-12-10 23:52:46.000000000 -0500
@@ -275,6 +275,8 @@
break;
case VIA_APOLLO_KT133: head->chipset = "VIA Apollo KT133";
break;
+ case VIA_APOLLO_PRO266: head->chipset = "VIA Apollo Pro266";
+ break;
#endif
case VIA_APOLLO_PRO: head->chipset = "VIA Apollo Pro";
diff -urN linux-agp/drivers/char/drm/drm_agpsupport.h~ linux/drivers/char/drm/drm_agpsupport.h
--- linux-agp/drivers/char/drm/drm_agpsupport.h~ 2002-12-06 02:07:34.000000000 -0500
+++ linux/drivers/char/drm/drm_agpsupport.h 2002-12-10 23:50:43.000000000 -0500
@@ -281,6 +281,8 @@
break;
case VIA_APOLLO_PRO: head->chipset = "VIA Apollo Pro";
break;
+ case VIA_APOLLO_PRO266: head->chipset = "VIA Apollo Pro266";
+ break;
case SIS_GENERIC: head->chipset = "SiS"; break;
case AMD_GENERIC: head->chipset = "AMD"; break;
diff -urN linux-agp/include/linux/agp_backend.h~ linux/include/agp_backend.h
--- linux-agp/include/linux/agp_backend.h~ 2002-12-03 21:07:09.000000000 -0500
+++ linux/include/linux/agp_backend.h 2002-12-10 04:25:59.000000000 -0500
@@ -57,6 +57,7 @@
VIA_VP3,
VIA_MVP3,
VIA_MVP4,
+ VIA_APOLLO_PRO266,
VIA_APOLLO_PRO,
VIA_APOLLO_KX133,
VIA_APOLLO_KT133,
diff -urN linux-agp/drivers/char/agp/agpgart_be.c~ linux/drivers/char/agp/agpgart_be.c
--- linux-agp/drivers/char/agp/agpgart_be.c~ 2002-12-02 19:20:22.000000000 -0500
+++ linux/drivers/char/agp/agpgart_be.c 2002-12-07 04:09:59.000000000 -0500
@@ -4714,6 +4714,12 @@
"Via",
"Apollo Pro KT266",
via_generic_setup },
+ { PCI_DEVICE_ID_VIA_8633_0,
+ PCI_VENDOR_ID_VIA,
+ VIA_APOLLO_PRO266,
+ "Via",
+ "Apollo Pro266",
+ via_generic_setup },
{ 0,
PCI_VENDOR_ID_VIA,
VIA_GENERIC,
^ permalink raw reply
* DMA Help
From: Nageswari S @ 2002-12-11 5:53 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am porting USB OHCI driver to a custom PowerPC 405 based platform with no
PCI Bus. I have taken SA1111 as a reference. USB uses DMA for its memory
transfers. How can I check proper functioning of DMA. Any help/suggestion
will be highly appreciated.
Thankyou,
regards,
Nageswari
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [PATCH] remove error message on illegal ioctl
From: Robert Love @ 2002-12-11 5:56 UTC (permalink / raw)
To: linux-kernel
Linus is away so I am just throwing this out on lkml..
This error message is uber annoying and needs to go. Non-root can flood
the console with this junk on invalid SCSI CD-ROM ioctl(), and that is
exactly what gnome-cd does.
An illegal ioctl() returns an error to the program. That is sufficient
- we do not need KERN_ERROR warnings all over the place. Especially
when any user can cause them at any rate.
This patch, against 2.5.51, removes the message.
Robert Love
drivers/scsi/sr_ioctl.c | 3 ---
1 files changed, 3 deletions(-)
diff -urN linux-2.5.51-mm1/drivers/scsi/sr_ioctl.c linux/drivers/scsi/sr_ioctl.c
--- linux-2.5.51-mm1/drivers/scsi/sr_ioctl.c 2002-12-10 17:45:03.000000000 -0500
+++ linux/drivers/scsi/sr_ioctl.c 2002-12-11 00:44:24.000000000 -0500
@@ -156,9 +156,6 @@
err = -ENOMEDIUM;
break;
case ILLEGAL_REQUEST:
- if (!cgc->quiet)
- printk(KERN_ERR "%s: CDROM (ioctl) reports ILLEGAL "
- "REQUEST.\n", cd->cdi.name);
err = -EIO;
if (SRpnt->sr_sense_buffer[12] == 0x20 &&
SRpnt->sr_sense_buffer[13] == 0x00)
^ permalink raw reply
* [PATCH] printks in drivers/scsi/hosts.c missing return
From: Robert Love @ 2002-12-11 5:55 UTC (permalink / raw)
To: linux-kernel
Linus is away so I am just throwing this out on lkml...
Trivial but annoying: two printk() calls in drivers/scsi/hosts.c are
missing '\n'
Also, for some reason I have not yet investigated, shost_tp->name is
NULL here. This should not be, eh? If it can be, we should do
something to tidy up the printing of it.
Patch is against 2.5.51.
Robert Love
drivers/scsi/hosts.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -urN linux-2.5.51-mm1/drivers/scsi/hosts.c linux/drivers/scsi/hosts.c
--- linux-2.5.51-mm1/drivers/scsi/hosts.c 2002-12-10 17:45:02.000000000 -0500
+++ linux/drivers/scsi/hosts.c 2002-12-11 00:40:28.000000000 -0500
@@ -488,14 +488,14 @@
if (!shost_tp->max_sectors) {
printk(KERN_WARNING
"scsi HBA driver %s didn't set max_sectors, "
- "please fix the template", shost_tp->name);
+ "please fix the template\n", shost_tp->name);
shost_tp->max_sectors = 1024;
}
if (!shost_tp->release) {
printk(KERN_WARNING
"scsi HBA driver %s didn't set a release method, "
- "please fix the template", shost_tp->name);
+ "please fix the template\n", shost_tp->name);
shost_tp->release = &scsi_host_legacy_release;
}
^ permalink raw reply
* 2.5.51 ide module problem
From: Jeff Chua @ 2002-12-11 5:49 UTC (permalink / raw)
To: Linux Kernel
My linux/.config ...
CONFIG_IDE=m
CONFIG_BLK_DEV_IDE=m
CONFIG_BLK_DEV_IDEDISK=m
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_IDE_MODES=y
System version ...
module-init-tools-0.9.3
linux-2.5.51
depmod will ecounter "Segmentation fault" if the ide.ko and ide-io.ps
modules are in /lib/modules/2.5.51/kernel
After "rm ide.ko ide-io.ps", depmod runs fine, but that means ide won't
load.
Thanks,
Jeff
[ jchua@fedex.com ]
^ permalink raw reply
* incompatable pointer type warnings on some archs
From: James H. Cloos Jr. @ 2002-12-11 5:48 UTC (permalink / raw)
To: linux-kernel
I see that find_next_zero_bit() has a first arg of void* in about half
of the archs and unsigned long* in the rest (incl asm-i386/bitops.h).
Looking at incompatable pointer type warnings in a recent compile, I
found one where the caller was passing a u64*, thus the error.
Should all of the archs use a void* for this, or is there some reason
not to?
test_and_set_bit() and test_and_clear_bit() also have the same issue.
-JimC
^ permalink raw reply
* Re: Re: documentation or lack thereof
From: Kevin Conder @ 2002-12-11 5:37 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <E18Lut8-0005PF-00@sc8-sf-list2.sourceforge.net>
> > 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.
>
> 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.
>
> 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.
Perhaps you're referring to me... It's true that I am busy with the
Alternative Csound Reference Manual these days. But I will help convert
ALSA documentation to DocBook/SGML (or Docbook/XML), if asked. I'm
currently helping Takashi with his HOWTO.
=====
-- kwconder at yahoo dot com
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------------------------------------------
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: xxx_check_var
From: James Simmons @ 2002-12-11 6:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, linux-kernel, linux-fbdev-devel
In-Reply-To: <1039562028.3373.32.camel@zion>
> > When I look at atyfb_check_var or aty128fb_check_var, I see that they
> > will alter the contents of *info->par. Isn't this a bad thing? My
>
> Yes, this wrong, and afaik, it's your original port to 2.5 that did that
> ;)
Yeap. The idea of check_var is to validate a mode. Note modedb uses just
check_var. It is okay to READ the values in your par. You shouldn't alter
the values in par.
> > understanding was that after calling check_var, you don't necessarily
> > call set_par next (particularly if check_var returned an error).
Correct. Check_var is always called. Now if you wanted to just test a mode
via userland with the FB_ACTIVATE_TEST flag then only fb_check_var is
called. If you pass in FB_ACTIVATE_NOW then both fb_check_var and
fb_set_par will be called. Fb_set_par actually sets the hardware state.
> > Also I notice that atyfb_set_par and aty128fb_set_par don't look at
> > info->var, they simply set the hardware state based on the contents of
> > *info->par.
>
> Which is wrong too indeed
Actually you can look at info->var. Info->var has been validated so it can
be trusted. You don't need to stuff everything into par. You DO need to
change info->fix if the hardware state has changed.
> > Looking at skeletonfb.c, it seems that this is the wrong behaviour. I
> > had fixed the aty128fb.c driver in the linuxppc-2.5 tree. James, if
> > you let me know whether the current behaviour is wrong or not, I'll
> > fix them and send you the patch.
I hope me input helped.
BTW docs are on the way. I will work with Steven Luther on this the next
couple of days.
> I _think_ my radeonfb (in linuxppc-2.5) is right in this regard too.
> Look at the initialization too, iirc, you had some non necessary stuff
> in there (calling gen_set_disp, gen_set_var is plenty enough).
You go the logic down.
P.S
For the pmu_sleep_notifier can you pass in a specific struct fb_info or
do you need to make a list of all of them?
^ permalink raw reply
* Re: Problem with mm1 patch for 2.5.51
From: Robert Love @ 2002-12-11 5:38 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux kernel mailing list, Andrew Morton
In-Reply-To: <1039583335.3df6c8677cff4@kolivas.net>
On Wed, 2002-12-11 at 00:08, Con Kolivas wrote:
> I suspect I suffered a similar fate with the osdl test box. While I was away
> letting it run a benchmark in smp mode the filesystem had remounted read only. I
> tried rebooting to make some sense of what had happened but was unable to start
> the machine with any kernel. I've asked the osdl people to have a look at the
> box for me.
>
> Previously a run in uniprocessor mode ran flawlessly.
This looks like a fix to the ext3 bug I posted last week, which was on
UP.
It comes and goes... I am in 2.5-mm with no problems now, but it was
killing me last week. *shrug*
Here's to hoping this fixes it...
Robert Love
^ permalink raw reply
* Re: soundcard matrix: broken links etc.
From: Patrick Shirkey @ 2002-12-11 5:27 UTC (permalink / raw)
To: John S. Denker; +Cc: alsa-devel
In-Reply-To: <3DF6B9A5.3010807@monmouth.com>
John S. Denker wrote:
> However, the apparently non-deprecated version
> http://www.alsa-project.org/alsa-doc/
> contains almost as many broken links etc.
> Here's the summary:
>
> Code Occurrences What to do
> 200 1 There are broken fragments which must be fixed.
> 301 1 You should update the link.
> 302 28 Usually nothing.
> 401 4 The link is not public. You'd better specify it.
> 403 1 The link is forbidden! This needs fixing.
> 404 57 The link is broken. Fix it NOW!
> 405 1 The server does not allow HEAD requests.
> 500 37 Either the hostname is incorrect or ...
>
> Interested parties may grab the details from
> http://www.av8n.net/~jsd/alsa/checked-links2.html
> http://www.av8n.net/~jsd/alsa/checked-links2.html.gz
>
Thanks for that. If you have the inclination to send in a patch that
would be very appreciated. Otherwise it will have to wait for me to get
some more time.
--
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:
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
* [PATCH] AGP support VIA VT8633
From: Nathaniel Russell @ 2002-12-11 5:21 UTC (permalink / raw)
To: marcelo; +Cc: linux-kernel, alan, reddog83
[-- Attachment #1: Type: TEXT/PLAIN, Size: 326 bytes --]
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
[-- Attachment #2: Via VT8633 Support --]
[-- Type: TEXT/PLAIN, Size: 1977 bytes --]
diff -urN linux-agp/drivers/char/drm-4.0/agpsupport.c~ linux/drivers/char/drm-4.0/agpsupport.c
--- linux-agp/drivers/char/drm-4.0/agpsupport.c~ 2002-12-03 21:07:08.000000000 -0500
+++ linux/drivers/char/drm-4.0/agpsupport.c 2002-12-10 23:52:46.000000000 -0500
@@ -275,6 +275,8 @@
break;
case VIA_APOLLO_KT133: head->chipset = "VIA Apollo KT133";
break;
+ case VIA_APOLLO_PRO266 head->chipset = "VIA Apollo Pro266";
+ break;
#endif
case VIA_APOLLO_PRO: head->chipset = "VIA Apollo Pro";
diff -urN linux-agp/drivers/char/drm/drm_agpsupport.h~ linux/drivers/char/drm/drm_agpsupport.h
--- linux-agp/drivers/char/drm/drm_agpsupport.h~ 2002-12-06 02:07:34.000000000 -0500
+++ linux/drivers/char/drm/drm_agpsupport.h 2002-12-10 23:50:43.000000000 -0500
@@ -281,6 +281,8 @@
break;
case VIA_APOLLO_PRO: head->chipset = "VIA Apollo Pro";
break;
+ case VIA_APOLLO_PRO266 head->chipset = "VIA Apollo Pro266";
+ break;
case SIS_GENERIC: head->chipset = "SiS"; break;
case AMD_GENERIC: head->chipset = "AMD"; break;
diff -urN linux-agp/include/linux/agp_backend.h~ linux/include/agp_backend.h
--- linux-agp/include/linux/agp_backend.h~ 2002-12-03 21:07:09.000000000 -0500
+++ linux/include/linux/agp_backend.h 2002-12-10 04:25:59.000000000 -0500
@@ -57,6 +57,7 @@
VIA_VP3,
VIA_MVP3,
VIA_MVP4,
+ VIA_APOLLO_PRO266,
VIA_APOLLO_PRO,
VIA_APOLLO_KX133,
VIA_APOLLO_KT133,
diff -urN linux-agp/drivers/char/agp/agpgart_be.c~ linux/drivers/char/agp/agpgart_be.c
--- linux-agp/drivers/char/agp/agpgart_be.c~ 2002-12-02 19:20:22.000000000 -0500
+++ linux/drivers/char/agp/agpgart_be.c 2002-12-07 04:09:59.000000000 -0500
@@ -4714,6 +4714,12 @@
"Via",
"Apollo Pro KT266",
via_generic_setup },
+ { PCI_DEVICE_ID_VIA_8633_0,
+ PCI_VENDOR_ID_VIA,
+ VIA_APOLLO_PRO266,
+ "Via",
+ "Apollo Pro266",
+ via_generic_setup },
{ 0,
PCI_VENDOR_ID_VIA,
VIA_GENERIC,
^ permalink raw reply
* Re: "bio too big" error
From: Andrew Morton @ 2002-12-11 5:18 UTC (permalink / raw)
To: Wil Reichert; +Cc: linux-kernel
In-Reply-To: <1039577938.388.9.camel@darwin>
Wil Reichert wrote:
>
> Exact error with debug is:
>
> darwin:/a01/mp3s/Skinny Puppy/Too Dark Park# ogg123 -q 01\ -\
> Convulsion.ogg
> bio too big device ide0(3,4) (256 > 255)
> Call Trace: [<c020055e>] [<e09ff46d>] [<e09ff558>] [<e09ff5f5>]
> [<c020050a>] [<c02005f4>] [<c017048e>] [<c0170a79>] [<c0187770>]
> [<c01472e6>] [<c0187770>] [<c0140edd>] [<c01977fc>] [<c01473e4>]
> [<c01475be>] [<c0137ac8>] [<c0137e60>] [<c0138124>] [<c0137e60>]
> [<c01381ca>] [<c014eadb>] [<c01094cb>]
> [<e09def98>] [<c01113bf>] [<c0110ac2>] [<c014ebce>] [<c014ee6e>]
> [<c010967f>]
>
Could you please enable CONFIG_KALLSYMS and regenerate the backtrace?
Thanks.
^ permalink raw reply
* Re: problems build usb-serial as a module in 2.5.51
From: Greg KH @ 2002-12-11 5:14 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
In-Reply-To: <200212102109.18143.tomlins@cam.org>
On Tue, Dec 10, 2002 at 09:09:18PM -0500, Ed Tomlinson wrote:
> I get this building 2.5.51
>
> make -f scripts/Makefile.build obj=drivers/usb/serial
> gcc -Wp,-MD,drivers/usb/serial/.usb-serial.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=k6 -Iarch/i386/mach-generic -nostdinc -iwithprefix include -DMODULE -DKBUILD_BASENAME=usb_serial -DKBUILD_MODNAME=usbserial -DEXPORT_SYMTAB -c -o drivers/usb/serial/usb-serial.o drivers/usb/serial/usb-serial.c
> {standard input}: Assembler messages:
> {standard input}:2592: Error: value of -129 too large for field of 1 bytes at 5820
What version of gcc and what is your .config for the CONFIG_USB_SERIAL_*
options?
thanks,
greg k-h
^ permalink raw reply
* [Linux-ia64] Extra do_fork arg for clone2
From: Ian Wienand @ 2002-12-11 5:05 UTC (permalink / raw)
To: linux-ia64
Hello,
Due to the recent changes to clone flags by Ingo Molnar (see
http://www.gelato.unsw.edu.au/~ianw/clone2.txt if anyone missed the
thread) we need an extra argument to do_fork. this doesn't seem to be
in the 2.5.50 pre-patch.
suggested patch below.
thanks
-i
ianw@gelato.unsw.edu.au
--- 1.24/arch/ia64/kernel/entry.S Mon Nov 25 10:27:51 2002
+++ 1.25/arch/ia64/kernel/entry.S Wed Dec 11 15:04:10 2002
@@ -91,11 +91,11 @@
END(ia64_execve)
/*
- * sys_clone2(u64 flags, u64 ustack_base, u64 ustack_size, u64 user_tid, u64 tls)
+ * sys_clone2(u64 flags, u64 ustack_base, u64 ustack_size, u64 parent_tidptr, u64 child_tidptr, u64 tls)
*/
GLOBAL_ENTRY(sys_clone2)
.prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(2)
- alloc r16=ar.pfs,5,2,5,0
+ alloc r16=ar.pfs,6,2,6,0
DO_SAVE_SWITCH_STACK
adds r2=PT(R16)+IA64_SWITCH_STACK_SIZE+16,sp
mov loc0=rp
@@ -104,9 +104,10 @@
mov out1=in1
mov out3=in2
tbit.nz p6,p0=in0,CLONE_SETTLS_BIT
- mov out4=in3 // valid only w/CLONE_SETTID and/or CLONE_CLEARTID
+ mov out4=in3 // parent_tidptr
+ mov out5=in4 // child_tidptr
;;
-(p6) st8 [r2]=in4 // store TLS in r13 (tp)
+(p6) st8 [r2]=in5 // store TLS in r13 (tp)
adds out2=IA64_SWITCH_STACK_SIZE+16,sp // out2 = ®s
dep out0=0,in0,CLONE_IDLETASK_BIT,1 // out0 = clone_flags & ~CLONE_IDLETASK
br.call.sptk.many rp=do_fork
^ permalink raw reply
* Re: "bio too big" error
From: Greg KH @ 2002-12-11 5:11 UTC (permalink / raw)
To: Wil Reichert; +Cc: Andrew Morton, Jens Axboe, linux-kernel
In-Reply-To: <1039577938.388.9.camel@darwin>
On Tue, Dec 10, 2002 at 10:38:58PM -0500, Wil Reichert wrote:
>
> I'm guessing its perhaps a 2.5 / lvm issue? Here's 'vgdisplay -v' in
> case:
Did you try the dm patches that were just posted to lkml today?
thanks,
greg k-h
^ permalink raw reply
* ipsec & nat
From: Simpson, Doug @ 2002-12-11 5:03 UTC (permalink / raw)
To: 'netfilter@lists.netfilter.org'
I have a redhat 7.3 box that is dualhomed. It is my firewall and vpn
server. I can successfully vpn (with IPSEC) into it. If I use the
following command "iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE" I
cannot use VPN, but my internal network can only receive email (POP3) and
telnet after I use this command.
I have set up squid so I proxy my www traffic.
Can I NAT my pop3 and my telnet, and still VPN (IPSEC)?
I am guessing my command is too general and I need to be more specific -
ports, source, etc defined.
Thanks,
Doug
^ permalink raw reply
* Anti-virus for Sendmail
From: Manoj Sharma @ 2002-12-11 5:02 UTC (permalink / raw)
To: linux-admin
Hello All,
I need suggestions for a Anti-virus for my mail server
(Running Sendmail on RedHat Linux)
Thanks in advance.
--
Manoj Sharma
^ 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.