* Re: Anti-virus for Sendmail
From: Nicolas Costes @ 2002-12-11 10:18 UTC (permalink / raw)
To: linux-admin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le Mercredi 11 Décembre 2002 02:30, dashielljt a écrit :
> Does anyone know of an antivirus package for linux that doesn't need any
> gui interface to run? I'm using text only here since my screen reader
> likes it that way. If the screen reader doesn't work on this system
> either speakup or emacspeak the computer isn't providing me any useful
> output.
Have you tried Amavis (http://www.amavis.org/) ???
It works as an interface between sendmail (Or another MTA, like postfix) and
antivirus software. I automatically recognizes those one, if they're already
installed. It's better to use the "amavisd-new" version (or amavisd).
- - --
,,
( °> Nicolas Costes
/||\ IUT de La Roche / Yon
( ^ ) Nayco@iut-laroche.univ-nantes.fr
^ ^ http://luxregina.free.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE99xDYDeRAHGw6DGURAkhmAJ9JDQDi8jhgX/Mc3Zxgc0w/7qkYOwCgmKG1
1Ncnt7PQ9F6plG9kKOsEwek=
=atSa
-----END PGP SIGNATURE-----
-
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: RAV antivirus?
From: Catalin Bucur @ 2002-12-11 10:17 UTC (permalink / raw)
To: Manoj Sharma; +Cc: linux-admin
In-Reply-To: <200212110107.43590.manoj@tacitnetworks.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Manoj Sharma wrote:
| Has anyone used RAV antivirus for the mailservers (Sendmail, RedHat
Linux)?
| Do you recommend this Anti Virus for Sendmail?
|
~From my point of view, yes. I'm using this antivirus for nine months
now, and it's working fine. They have online support and mailing-list.
You can download a trial version from their web page:
http://www.ravantivirus.com/
- --
Catalin Bucur mailto:cata@geniusnet.ro
NOC @ Genius Network SRL - Galati - Romania
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE99xDRpDe20wwI9oIRAiqIAJ9CUiHQed1iY3gpMxmD1jLuf01RZwCfdlO5
AQ3rA94Q527uH1V10rsN/A8=
=FSMA
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Possibly defective BIOS detected (irqtable)
From: uaca @ 2002-12-11 10:15 UTC (permalink / raw)
To: Mailing list de Linux-SMP
In-Reply-To: <1039537039.14175.12.camel@irongate.swansea.linux.org.uk>
On Tue, Dec 10, 2002 at 04:17:19PM +0000, Alan Cox wrote:
> On Tue, 2002-12-10 at 10:06, uaca@alumni.uv.es wrote:
> >
> > Hi all
> >
> > I have a "VALinux FullOn 2230" PIII SMP processor system (2 processors) with
> > Intel's 440GX chipset
>
> If your box works you are ok, if not well Intel have been refusing for a
> long time to tell us how to handle it
Hi all
I'm going myself to complement this thread someway, I hope this helps others
The motherboard that has this system (and probably other VALinux systems)
are made by Intel (all the motherboard, not just the chipset)
in this case the motherboard name is "Intel® L440GX+ server board."
You can identify the name/model/version of any Intel motherboard following
this procedure
http://support.intel.com/support/motherboards/identify.htm
This motherboard is a discontinued product
http://support.intel.com/support/motherboards/server/pdal.htm
But there are bios upgrades and some docs in this motherboard's page
http://support.intel.com/support/motherboards/server/L440GX/
This motherboard seems to not have a flash chip wich could be programmed
offline but it has a procedure to upgrade it again if everything fails
described in "Intel(R) L440GX Server Board - Technical Product Specification
[254151-003.PDF]"
next days I'm probably going to do a bios upgrade and I'll add a followup
in this thread
Ulisses
Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers." Pablo Picasso
---> Visita http://www.valux.org/ para saber acerca de la <---
---> Asociación Valenciana de Usuarios de Linux <---
^ permalink raw reply
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Ducrot Bruno @ 2002-12-11 10:14 UTC (permalink / raw)
To: Andrew McGregor; +Cc: Linux Kernel Mailing List, ACPI mailing list
In-Reply-To: <23440000.1039553448-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Wed, Dec 11, 2002 at 09:50:48AM +1300, Andrew McGregor wrote:
> I strongly suspect that s4bios will work on this machine, but swsusp won't.
> Why? It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia
> put pm support in their driver, it's game over for Linux. Except that the
> BIOS knows how to suspend it, so some kernel/driver combinations work with
> APM. I suspect any Geforce2go Dell is the same.
No. You are wrong. I need to suspend allmost all the drivers, and the
video chipset is not an execption (or go to a console before suspending,
in fact).
You still need to bug NVIDIA in order to have proper pm support
in their driver.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply
* Re: Expeiment with a simple boot?
From: Helge Hafting @ 2002-12-11 10:16 UTC (permalink / raw)
To: wz6b, linux-kernel
In-Reply-To: <200212100954.33462.wz6b@arrl.net>
Matt Young wrote:
>
> 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)
Sure. You don't need devfs to boot. And you don't need any
initrd either, of course. Just compile the drivers for your root disk
and your root fs into the kernel instead of using modules for them.
I never used an initrd - no need.
I do this with lilo all the time, as I haven't looked at grub.
Helge Hafting
^ permalink raw reply
* Re: Linux 2.5.51
From: Benjamin Herrenschmidt @ 2002-12-11 10:21 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: James Simmons, Stian Jordet, Allan Duncan, linux-kernel
In-Reply-To: <m1smx4vrem.fsf@frodo.biederman.org>
On Wed, 2002-12-11 at 10:25, Eric W. Biederman wrote:
> > Well, I'm not sure it quite works yet. Maybe unaccelerated, but anyway,
> > my version of radeonfb for 2.5 isn't accelerated yet anyway. I'll work
> > on that (or Ani will) now that the API is stable enough.
>
> How well does this driver work if you don't have a firmware
> driver initialize the card? aka a pci option ROM.
Probably not at all
> I am interested because with LinuxBIOS it is still a pain to run
> PCI option roms, and I don't necessarily even have then if it a
> motherboard with video. There are some embedded/non-x86 platforms
> with similar issues.
Well, at least r128's and radeon's need the memory controller and PLLs
initialized by the BIOS/firmware, we don't have documentation about how
to acheive that ourselves (and this can depend on the specific wiring of
a given card anyway).
> My primary interest is in the cheap ATI Rage XL chip that is on many
> server board. PCI Vendor/device id 1002:4752 (rev 27) from lspci.
>
> If nothing else if some one could point me to some resources on
> how to get the appropriate documentation from the video chipset
> manufacturers I would be happy.
>
> But I did want to at least point that running a system with out bios
> initialized video was certainly among the cases that are used.
This is not possible with most modern cards without specific POST code
provided by the chip manufacturer.
Ben.
^ permalink raw reply
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Ducrot Bruno @ 2002-12-11 10:07 UTC (permalink / raw)
To: Pavel Machek
Cc: Alan Cox, Grover, Andrew, 'Ducrot Bruno', Ducrot Bruno,
Patrick Mochel, Linux Kernel Mailing List, ACPI mailing list
In-Reply-To: <20021210204031.GF20049-jyMamyUUXNJG4ohzP4jBZS1Fcj925eT/@public.gmane.org>
On Tue, Dec 10, 2002 at 09:40:31PM +0100, Pavel Machek wrote:
> Hi!
>
> > > I concur with your pros and cons. This makes me think that if S4BIOS support
> > > ever gets added, it should get added to 2.4 only.
>
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.
Well, it worked for me with 2.4 with 'basic' pm_send_xxx
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Ducrot Bruno @ 2002-12-11 10:14 UTC (permalink / raw)
To: Andrew McGregor; +Cc: Linux Kernel Mailing List, ACPI mailing list
In-Reply-To: <23440000.1039553448@localhost.localdomain>
On Wed, Dec 11, 2002 at 09:50:48AM +1300, Andrew McGregor wrote:
> I strongly suspect that s4bios will work on this machine, but swsusp won't.
> Why? It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia
> put pm support in their driver, it's game over for Linux. Except that the
> BIOS knows how to suspend it, so some kernel/driver combinations work with
> APM. I suspect any Geforce2go Dell is the same.
No. You are wrong. I need to suspend allmost all the drivers, and the
video chipset is not an execption (or go to a console before suspending,
in fact).
You still need to bug NVIDIA in order to have proper pm support
in their driver.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Ducrot Bruno @ 2002-12-11 10:07 UTC (permalink / raw)
To: Pavel Machek
Cc: Alan Cox, Grover, Andrew, 'Ducrot Bruno', Ducrot Bruno,
Patrick Mochel, Linux Kernel Mailing List, ACPI mailing list
In-Reply-To: <20021210204031.GF20049@atrey.karlin.mff.cuni.cz>
On Tue, Dec 10, 2002 at 09:40:31PM +0100, Pavel Machek wrote:
> Hi!
>
> > > I concur with your pros and cons. This makes me think that if S4BIOS support
> > > ever gets added, it should get added to 2.4 only.
>
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.
Well, it worked for me with 2.4 with 'basic' pm_send_xxx
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply
* Re: Regarding consistent_alloc
From: Pantelis Antoniou @ 2002-12-11 9:58 UTC (permalink / raw)
To: joakim.tjernlund
Cc: acurtis, Tom Rini, Dan Malek, Paul Mackerras, Matt Porter,
linuxppc-embedded
In-Reply-To: <IGEFJKJNHJDCBKALBJLLAELIFIAA.joakim.tjernlund@lumentis.se>
Joakim Tjernlund wrote:
>>
>>>>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?
>>>>
>
>It would be great if the new fucntions could work with micropatch.c as well.
>If the microcode is loaded, then those microcode area should be reserved and
>not used by 8xx_cpm_dpalloc.
>
As a matter of fact, this is another patch that I can submit
that take into account the area left by the micropatches so that the
dpalloc functions can utilize every last byte of the DPRAM.
At the moment I'm swamped with work, so it will take a couple of
days to clean things up and submit them.
>
>>><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>
>>>
>>m8xx_cpm_hostalloc(), if it is anything like the 8260 version, enables you
>>to allocation memory from dual-port RAM. (which could be handy and/or
>>required for certain CPM related operations) _va() and _pa() only work for
>>main memory addresses. For all other address ranges the iopa() function must
>>be used. (I hope this is helpful)
>>
>
>_va() and _pa() used to work for m8xx_cpm_hostalloc() and I like that better. _pa()
>is much cheaper than iopa() and there is no iova()(I think).
>
>Why was m8xx_cpm_hostalloc() changed to use consistent_alloc()? alloc_bootmem_pages()
>should still work(I am guessing)
>
>BTW, m8xx_setup_arch() still calls alloc_bootmem_pages() and
>the new m8xx_cpm_reset() does not take a ptr argument, but m8xx_setup_arch()
>still calls m8xx_cpm_reset() with cpm_page as argument.
>
I think it's safe to assume that there is large amount of confussion at
this subject.
FWIW I dislike the use of iopa(), and I would be forced to duplicate the
code of
consistent_alloc() class of functions in my tree.
Could we at least have a m8xx_cpm_hostalloc that works as expected?
How about the following approach:
Each platform which is based on 8xx defines the amount of uncached
memory that is expected
to be used by it's drivers. It's not hard to make a rough estimation
since most people
that use the 8xx have very tight control of the hardware.
We organize then the memory in a heap, which is able to do allocations and
deallocations properly. That allows drivers that are loaded as modules
to operate
correctly and does not fragment (much) the memory.
How about it?
>
> Jocke
>
>
>
>
P.S. I have posted by QMC driver to the list, but there has been no
response.
Please if anyone is interested in the QMC, give me some kind of feedback.
Even negative feedback is OK.
Thanks
--
Pantelis Antoniou
INTRACOM S.A. Greece
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 2.5.51 won't boot with devfs enabled
From: Helge Hafting @ 2002-12-11 10:00 UTC (permalink / raw)
To: ebuddington, linux-kernel
In-Reply-To: <20021210111835.A92@ma-northadams1b-112.bur.adelphia.net>
Eric Buddington wrote:
>
> With 2.5.51 (gcc-3.2, Athlon, mostly modules, DEVFS=y, DEVFS_DEBUG=y),
> boot panics with "VFS: Cannot open root device "hda1" or
> 03:01".
>
> I had the same problem with 2.5.50, avoidable by disabling devfs entirely.
>
> -Eric
> -
> 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/
Booting anything later than 2.5.48 with devfs configured
either needs an extra kernel parameter, or a code change.
Something broke when do_mounts.c were reorganized.
It doesn't matter wether devfs is used or not, as long as it
is configured.
The lilo solution:
lilo tend to have a "root=/dev/hda1" or similiar.
This gets converted to "root=0301" on the kernel command line.
(Look at dmesg after a successful boot)
But this don't work for some reason when devfs is configured.
Use the following:
append="root=/dev/hda1"
to solve the problem. This isn't converted to numbers and works.
Of course if you use auto-mounted devfs then you don't
have a /dev/hda1 but a /dev/ide/host0/bus0/target0/lun0/part1
instead. If so, use that as root instead. You still have
to use the append= trick.
The code solution:
Edit init/do_mounts.c
Remove the following lines from the beginning of
the function prepare_namespace:
#ifdef CONFIG_DEVFS_FS
sys_mount("devfs", "/dev", "devfs", 0, NULL);
do_devfs = 1;
#endif
Then recompile, and the kernel should work with any lilo setup that
worked for 2.5.47 and earlier. At least it worked for the setups
I tried.
This has no effect on kernels without devfs, and helps for kernels
comiled with devfs wether devfs is used or not.
I posted a patch for this, but there were no interest at all.
Helge Hafting
^ permalink raw reply
* Re: ip_conntrack_http?
From: Roberto Nibali @ 2002-12-11 9:56 UTC (permalink / raw)
To: Chris Shepherd; +Cc: Martin Josefsson, Netfilter mailinglist
In-Reply-To: <1039534152.3df60848b8692@mail.whstuart.com>
Hello,
While I think you've got a problem with your software architecture I assure you
that this can be handled with LVS.
>>No, this is how loadbalacing in iptables works, it balances the
>>individual connections.
>
> That's what I thought.
Load balancing done on a netfilter level is just not extremely intelligent. Use
LVS. It's the same story as with all the rather clumsy NF modules/enhancements,
like for example ROUTE. Use the tools that are given to you and don't cludge NF
with even more deisgns that are not complete. LVS does an excellent job at load
balancing, iproute2 does an excellent job on routing (and RR balancing too
actually).
>>>What happens now:
>>>CONN1a -> WS1
>>>CONN1b -> WS2
>>>CONN2a -> WS1
>>>CONN2b -> WS2
>>>
>>>What should happen:
>>>CONN1a -> WS1
>>>CONN1b -> WS1
>>>CONN2a -> WS2
>>>CONN2b -> WS2
>>>
>>>Provided that CONN1[ab] are related connections, but unrelated to
>>
>>CONN2[ab].
>>
>>How do you relate http connections to each other?
In LVS parlance you need persistency. The IP grouping can be achieved with
fwmark based load balancing, but in your case you won't need it anyway.
> Well, I would think the TCP RELATED flag should be set for the second
> connection from the browser. Not being a Netfilter programmer myself, I'm not
> sure if there's any connection identifier that's passed along with the RELATED
> connection information... If there was, would it not be possible to just
> forward all related connection IDs to one IP? So at most there should only be
> two or three connections in a group, and this would sort out situations where
> people sharing a connection would otherwise all end up on the same webserver,
> and not be effectively load balanced.
This is a problem, yes, but everyday reports on the LVS mailinglist do not
mention a big problem with this. Especially since the Internet is very dynamic
the load imbalance will eventually straighten out. So, don't worry about that.
> On the connection-level, is it possible to somehow see which connection a new
> connection is related to? If so, I would think it'd be logically easy, but not
> necessarily programmatically so.
It is relatively easy but not with netfilter. You can track connections with so
called connection templates and depending on the scheduler the templates vary.
It is much faster then netfilter.
> I will let you know when I get a chance to test it. I have the sneaky feeling
> that if this works properly (which it should), a lot of developers might wanna
> know about it. :)
I doubt this is a good solution. It may work but only solve a limited case of
load balancing.
>>>I am very interested in knowing, because it could save myself and a few
>>
>>dozen
>>
>>>webdevs I know a lot of money that we'd be spending on a hardware
>>
>>connection-
>>
>>>level load balancer.
Almost all the people on LVS save money by implementing LVS as a software load
balancer. It's made for that besides other reasons of course.
>>Other options may be the LVS, Linux Virtual Server project. I believe
>>they have loadbalancers and stuff for http.
Our load balancer doesn't really care about the protocol as long as it is L4.
>>From the documentation I've read, LVS does essentially the same thing as NF
> does: it forwards on a per connection basis. It too would succumb to this
> problem.
Please read the documentation again, you don't seem to have understood it. And
if you're still not sure about how it works, please join our newcomer-friendly
LVS mailinglist. Thanks.
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ 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-11 12:49 UTC (permalink / raw)
To: Miles Lane; +Cc: James Simmons, Linux Fbdev development list
In-Reply-To: <3DF6894E.3090802@attbi.com>
On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> Hi,
>
> I have tried getting rivafb to work in 2.5.51. It is much better
> than before (thanks!). It compiles and sorta works.
>
> 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 ---+
> | |
> | |
>
What's the hardware, is it on a big endian machine? I think there's a
typo there (__BIG_ENDIAN__ instead of __BIG_ENDIAN). This should
produce the "mirroring" effect.
Secondly, a lot of the changes there are for riva128, which may not
apply for all cards. Try doing fbset -accel false/true and see if
there's any effect. Or open linux/video/drivers/riva/fbdev.c, line 277
and comment out the line with the FB_ACCELF_TEXT. This should force the
hardware to do everything in software.
> Also, when I boot, the penguin logo looks like it is being rendered
> in about five colors. In addition, the text is black, except for
That's definitely a color map problem.
> the white underscore cursor, so all I can see is the cursor.
> 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.
>
I get this with every framebuffer driver, so this is generic.
> 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).
Because changes done via fbset are not passed to fbcon anymore. So
you'll see the display change, but fbcon still thinks it's still on
640x480. I guess James will add some support for that via the console.
I'll test it myself too with a riva128 PCI.
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
* [BENCHMARK] LM bench result for mm1 patch of 2.5.51
From: Aniruddha M Marathe @ 2002-12-11 10:01 UTC (permalink / raw)
To: linux-kernel
Hi,
Key findings after comparison with 2.5.51
1.performance for forc proc is bit less. Must be because of the code added to kernel/fork.c
2. mmap latency is a bit more.
3. pipe local communication bandwidth is quite less.
===============================================================================
kernel 2.5.51 with mm1
date: 11 December 2002
===============================================================================
L M B E N C H 2 . 0 S U M M A R Y
------------------------------------
(Alpha software, do not distribute)
Basic system parameters
----------------------------------------------------
Host OS Description Mhz
--------- ------------- ----------------------- ----
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host OS Mhz null null open selct sig sig fork exec sh
call I/O stat clos TCP inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
benchtest Linux 2.5.51 790 0.46 0.83 27 29 1.29 5.21 353 1554 8130
benchtest Linux 2.5.51 790 0.46 0.87 27 29 40 1.35 5.23 445 1627 8214
benchtest Linux 2.5.51 790 0.44 0.85 27 29 38 1.31 5.21 383 1568 8176
benchtest Linux 2.5.51 790 0.44 0.85 27 28 34 1.31 5.20 436 1589 8232
benchtest Linux 2.5.51 790 0.44 0.84 27 28 38 1.28 5.22 403 1593 8292
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
benchtest Linux 2.5.51 1.210 4.9400 14 9.1200 175 43 177
benchtest Linux 2.5.51 1.180 4.6400 14 5.7000 182 41 180
benchtest Linux 2.5.51 1.200 4.9600 20 5.7900 180 38 179
benchtest Linux 2.5.51 1.230 4.8400 14 14 183 44 180
benchtest Linux 2.5.51 1.260 4.5800 14 6.2600 180 40 180
*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
ctxsw UNIX UDP TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
benchtest Linux 2.5.51 1.210 8.605 21 35 60 125 159 165
benchtest Linux 2.5.51 1.180 7.995 21 35 60 125 159 166
benchtest Linux 2.5.51 1.200 8.216 21 35 60 125 137 166
benchtest Linux 2.5.51 1.230 8.123 21 35 60 126 141 167
benchtest Linux 2.5.51 1.260 8.175 21 35 60 127 158 167
File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page
Create Delete Create Delete Latency Fault Fault
--------- ------------- ------ ------ ------ ------ ------- ----- -----
benchtest Linux 2.5.51 119 59 385 128 651 1.008 4.00000
benchtest Linux 2.5.51 119 59 399 128 650 1.021 4.00000
benchtest Linux 2.5.51 119 59 390 126 652 0.999 4.00000
benchtest Linux 2.5.51 119 59 384 132 656 0.948 4.00000
benchtest Linux 2.5.51 119 59 385 132 651 0.984 4.00000
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
benchtest Linux 2.5.51 432 131 22 286 356 124 113 356 171
benchtest Linux 2.5.51 327 136 23 290 352 123 112 353 169
benchtest Linux 2.5.51 344 126 22 294 351 123 111 351 169
benchtest Linux 2.5.51 288 123 22 292 350 123 112 350 168
benchtest Linux 2.5.51 389 136 22 294 350 123 112 349 168
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
---------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- ---- ----- ------ -------- -------
benchtest Linux 2.5.51 790 3.798 8.8740 175
benchtest Linux 2.5.51 790 3.808 8.8840 176
benchtest Linux 2.5.51 790 3.808 8.8840 176
benchtest Linux 2.5.51 790 3.797 8.8830 177
benchtest Linux 2.5.51 790 3.808 8.8850 177
===============================================================================
kernel 2.5.51
date: 11 December 2002
===============================================================================
L M B E N C H 2 . 0 S U M M A R Y
------------------------------------
(Alpha software, do not distribute)
Basic system parameters
----------------------------------------------------
Host OS Description Mhz
--------- ------------- ----------------------- ----
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
benchtest Linux 2.5.51 i686-pc-linux-gnu 790
Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host OS Mhz null null open selct sig sig fork exec sh
call I/O stat clos TCP inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
benchtest Linux 2.5.51 790 0.46 0.83 27 28 32 1.28 5.07 362 1563 8041
benchtest Linux 2.5.51 790 0.46 0.87 27 28 39 1.30 5.08 329 1592 8081
benchtest Linux 2.5.51 790 0.44 0.80 27 28 31 1.28 5.08 360 1589 7988
benchtest Linux 2.5.51 790 0.46 0.83 27 28 35 1.30 5.08 341 1592 8047
benchtest Linux 2.5.51 790 0.46 0.80 27 28 36 1.28 5.09 386 1575 8086
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
benchtest Linux 2.5.51 1.170 4.8900 14 8.8900 177 40 180
benchtest Linux 2.5.51 1.240 5.0400 14 10 178 38 180
benchtest Linux 2.5.51 1.330 5.0500 14 6.4600 181 39 181
benchtest Linux 2.5.51 1.490 4.9800 14 6.9800 180 44 180
benchtest Linux 2.5.51 1.400 5.0100 14 7.1500 180 40 180
*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
ctxsw UNIX UDP TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
benchtest Linux 2.5.51 1.170 8.107 20 33 59 122 157 166
benchtest Linux 2.5.51 1.240 8.260 20 33 59 123 156 161
benchtest Linux 2.5.51 1.330 8.009 20 34 59 122 155 165
benchtest Linux 2.5.51 1.490 8.312 21 33 59 122 157 161
benchtest Linux 2.5.51 1.400 8.299 20 33 59 123 154 164
File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page
Create Delete Create Delete Latency Fault Fault
--------- ------------- ------ ------ ------ ------ ------- ----- -----
benchtest Linux 2.5.51 119 57 377 123 606 0.925 4.00000
benchtest Linux 2.5.51 119 57 390 124 621 0.932 4.00000
benchtest Linux 2.5.51 119 57 378 126 624 0.911 4.00000
benchtest Linux 2.5.51 119 57 380 119 615 0.922 4.00000
benchtest Linux 2.5.51 120 57 392 128 612 0.920 4.00000
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
benchtest Linux 2.5.51 381 93 23 294 356 125 114 356 171
benchtest Linux 2.5.51 392 133 22 295 353 124 113 354 170
benchtest Linux 2.5.51 432 137 22 295 352 123 112 354 169
benchtest Linux 2.5.51 436 137 22 294 351 123 112 352 169
benchtest Linux 2.5.51 373 136 23 291 350 123 112 351 168
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
---------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- ---- ----- ------ -------- -------
benchtest Linux 2.5.51 790 3.799 56 174
benchtest Linux 2.5.51 790 3.798 8.8820 176
benchtest Linux 2.5.51 790 3.808 8.8730 176
benchtest Linux 2.5.51 790 3.799 8.8820 176
benchtest Linux 2.5.51 790 3.808 8.8820 177
Regards,
---------------------------------------------------------------
Aniruddha Marathe
Systems Engineer,
4th floor, WIPRO technologies,
53/1, Hosur road,
Madivala,
Bangalore - 560068
Karnataka, India
Phone: +91-80-5502001 extension 5092
E-mail: aniruddha.marathe@wipro.com
---------------------------------------------------------------
^ permalink raw reply
* [PATCH] let 2.5.51 build
From: Thierry Vignaud @ 2002-12-11 9:51 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 69 bytes --]
this patch enable 2.5.51 kernel to build without sequencer support :
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: alsa-fix-compile.diff --]
[-- Type: text/x-patch, Size: 421 bytes --]
fix compiling without sequencer support
--- ./sound/synth/Makefile.tv 2002-12-10 22:02:00.000000000 -0500
+++ ./sound/synth/Makefile 2002-12-10 21:50:37.000000000 -0500
@@ -12,8 +12,8 @@
obj-$(CONFIG_SND_TRIDENT) += snd-util-mem.o
ifeq ($(subst m,y,$(CONFIG_SND_SEQUENCER)),y)
obj-$(CONFIG_SND_SBAWE) += snd-util-mem.o
+obj-$(CONFIG_SND) += emux/
endif
-obj-$(CONFIG_SND) += emux/
include $(TOPDIR)/Rules.make
^ permalink raw reply
* [LARTC] Q about "overlimit", and IMQ/NAT trick
From: christian mock @ 2002-12-11 9:39 UTC (permalink / raw)
To: lartc
hi,
I've successfully implemented shaping and policing with HTB for my
SDSL line.
Some tips&tricks I discovered which were not covered in the FAQs and
docs I read:
- To discover the appropriate rate for your line, flood it with
traffic and reduce the rate until the matching class starts to show
a consistent backlog -- only then you've managed to take the queue
away from your modems/routers and into the shaping box.
- The docs only speak about the IMQ device in connection with the
PREROUTING chain -- the problem is that at that point, incoming
packets are not de-masqueraded yet, so you can't fwmark and shape
depending on the internal address; I use
<iptables packet marking>
iptables -i $EXT_IF -A FORWARD -t mangle -j IMQ
without problems.
Questions:
I'm not quite sure if I shoot myself in the foot with that IMQ setup
-- packets get stuffed into the IMQ device from the mangle table, but
where and how do they "reappear" after shaping?
The other question that remains is: with "tc qdisc show", I see
overlimit!=0 only for the root qdisc -- I would have expected it to
increase on the queues or classes where actual rate > configured
rate... why is that?
ciao,
cm.
--
Actually, I found New Zealanders to be the most akin to Canadians.
They also feel the looming presense of a next door neighbour country
full of loud, excessively happy and somewhat simple people, and are a
little intimidated by it. -- Paul Tomblin
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: CD Writing in 2.5.51
From: Markus Plail @ 2002-12-11 9:46 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1039599708.711.9.camel@nirvana>
* mdew writes:
>On Wed, 2002-12-11 at 22:34, Markus Plail wrote:
>>You don't need any additional modules. Just don't activate ide-scsi by
>>either not appending ide-scsi/scsi=hdX or not compiling ide-scsi
>>support in the kernel.
>can i completely remove scsi support then? (I dont have any scsi device)
Yes.
regards
Markus
^ permalink raw reply
* Re: is not plain file nor directory
From: Keith Owens @ 2002-12-11 9:46 UTC (permalink / raw)
To: Wahib Nackad; +Cc: linux-kernel
In-Reply-To: <F155L9OqNHKEn8diHNK0001ecdb@hotmail.com>
On Wed, 11 Dec 2002 00:16:25 +0000,
"Wahib Nackad" <wahibn@hotmail.com> wrote:
>I'm able to compile kernel 2.4.20 via SRPMS with spec file without problem
>as long as I don't enable pcmcia support with the kernel. If I enable pcmcia
>support, then compilation fail when the 'make module_install' command runs
>and return the following error message for each pcmcia drivers:
>
>depmod:
>/var/tmp/kernel-2.4.20-root/lib/modules/2.4.20-1/pcmcia/xircom_tulip_cb.o is
>not plain file nor directory
depmod detects symlinks and resolves them, this error should never
happen for valid symlinks. Run depmod with -v, post the 10 lines
starting with 'resolving xircom_tulip_cb.o symlink'.
^ permalink raw reply
* Re: new DRI resume binary snapshots and patches available
From: Juan Quintela @ 2002-12-11 9:38 UTC (permalink / raw)
To: swsusp-LcL5texQODR2DW0IdvIQ2g
Cc: dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20021203232507.GA1723-V1rPnKwUOrA59+mn7qD7y50iERQUc4G+@public.gmane.org>
>>>>> "charl" == Charl P Botha <c.p.botha-ra0OqMccq8edIhEUFHOBvg@public.gmane.org> writes:
Hi
charl> New binary snapshots of the DRI suspend/resume modified Radeon drivers are
charl> available at http://cpbotha.net/dri_resume.html - these are the first DRI
charl> suspend/resume driver snapshots since the merge of XFree86 HEAD into the DRI
charl> tree. The updated patches are of course also available at the mentioned URL.
could you told me what X version against are your dri
patches?
I am having a bad time (not being an XFree hacker) to merge the X part
of your patch (the kernel patch was a no brainer).
Basically my problem is that there is not:
- ati/radeon_common.h file (and I didn't found any of the other
DRM_RADEON_* diffs).
- in the radeon_dri.c::RADEONDRIResume() has a call to
+ _ret = drmCommandNone(info->drmFD, DRM_RADEON_CP_RESUME);
I am completely unable to find that command in my XFree tree :(
I am using XFree86-4.2.1-11mdk. We used the gatos patch, but old ati
code don't have either that function :(
Any help or advice on where can I found the CVS change where the
drmCommandNone was introduced is welcome. I looked at the Changelogs
and see no mention of that changes :(
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
-------------------------------------------------------
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: BUG in 2.5.50
From: Jens Axboe @ 2002-12-11 9:43 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: Roy Sigurd Karlsbakk, Kernel mailing list
In-Reply-To: <Pine.LNX.4.50.0212090508390.2139-100000@montezuma.mastecende.com>
On Mon, Dec 09 2002, Zwane Mwaikambo wrote:
> Added Jens to CC to verify any incorrect information i may or may not put
> down.
>
> On Mon, 9 Dec 2002, Roy Sigurd Karlsbakk wrote:
>
> > installed 2.5.50 and got an OOPS after a short while. .
> > config is attached as tonjeconfig
> > /var/log/messages including dmesg and oops is attached as tonje_messages
>
> Perhaps this might help with debugging;
>
> He has CONFIG_BLK_DEV_IDE_TCQ enabled and his IBM supports it,
>
> when he gets to do_rw_disk();
>
> We know its a READ request
> if (rq_data_dir(rq) == READ) {
> if (blk_rq_tagged(rq))
> return hwif->ide_dma_queued_read(drive);
>
> ... the request isn't tagged so we drop down here...
>
> if (drive->using_dma && !hwif->ide_dma_read(drive))
> return ide_started;
>
> int __ide_dma_read (ide_drive_t *drive)
> ...
> if (HWGROUP(drive)->handler != NULL)
> BUG();
>
> and ->handler = ?
If tcq is enabled on the drive, rq _must_ be tagged.
--
Jens Axboe
^ permalink raw reply
* Re: CD Writing in 2.5.51
From: mdew @ 2002-12-11 9:41 UTC (permalink / raw)
To: Markus Plail; +Cc: Linux Kernel
In-Reply-To: <87fzt43nm4.fsf@web.de>
On Wed, 2002-12-11 at 22:34, Markus Plail wrote:
> * mdew writes:
> >So many howto's for writing in 2.4.x, simply put, what do i need
> >(kernel-wise) to get IDE CD writing going?
>
> >the lwn.net announcements dont really explain what needs to been done,
> >what modules need to be loaded (and what I dont need anymore) etc.
>
> You don't need any additional modules. Just don't activate ide-scsi by
> either not appending ide-scsi/scsi=hdX or not compiling ide-scsi
> support in the kernel.
can i completely remove scsi support then? (I dont have any scsi device)
-mdew
^ permalink raw reply
* Re: Linux 2.4.21-pre1 compile failure: drivers/net/pcmcia/fmvj18x_cs.c
From: Eyal Lebedinsky @ 2002-12-11 9:37 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
In-Reply-To: <Pine.LNX.4.50L.0212101834240.23096-100000@freak.distro.conectiva>
gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686
-malign-functions=4 -DMODULE -DMODVERSIONS -include
/data2/usr/local/src/linux-2.4-pre/include/linux/modversions.h
-nostdinc -iwithprefix include -DKBUILD_BASENAME=fmvj18x_cs -c -o
fmvj18x_cs.o fmvj18x_cs.c
fmvj18x_cs.c: In function `fmvj18x_config':
fmvj18x_cs.c:489: `PRODID_TDK_GN3410' undeclared (first use in this
function)
fmvj18x_cs.c:489: (Each undeclared identifier is reported only once
fmvj18x_cs.c:489: for each function it appears in.)
fmvj18x_cs.c:529: `MANFID_UNGERMANN' undeclared (first use in this
function)
make[3]: *** [fmvj18x_cs.o] Error 1
make[3]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre/drivers/net/pcmcia'
#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_AXNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_ARCNET_COM20020_CS=m
CONFIG_PCMCIA_IBMTR=m
CONFIG_PCMCIA_XIRCOM=m
CONFIG_PCMCIA_XIRTULIP=m
CONFIG_NET_PCMCIA_RADIO=y
CONFIG_PCMCIA_RAYCS=m
CONFIG_PCMCIA_NETWAVE=m
CONFIG_PCMCIA_WAVELAN=m
CONFIG_AIRONET4500_CS=m
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
^ permalink raw reply
* Re: CD Writing in 2.5.51
From: Markus Plail @ 2002-12-11 9:34 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1039598049.480.7.camel@nirvana>
* mdew writes:
>So many howto's for writing in 2.4.x, simply put, what do i need
>(kernel-wise) to get IDE CD writing going?
>the lwn.net announcements dont really explain what needs to been done,
>what modules need to be loaded (and what I dont need anymore) etc.
You don't need any additional modules. Just don't activate ide-scsi by
either not appending ide-scsi/scsi=hdX or not compiling ide-scsi
support in the kernel.
You also need a recent version of cdrtools. Just take the latest
cdrtools-2.0pre version. cdrdao won't work yet without moving the new
libscg from cdrtools to cdrdao, but it's not too hard to do and if you
complain on the cdrdao list they will perhaps update it themselves
sooner ;-)
After that is done you can burn your disks with dev=/dev/hdX.
regards
Markus
^ permalink raw reply
* Re: Status new-modules + 802.11b/IrDA
From: Rusty Russell @ 2002-12-11 8:34 UTC (permalink / raw)
To: jt; +Cc: Linux kernel mailing list, Jeff Garzik, dahinds, davem
In-Reply-To: <20021211010512.GA5853@bougret.hpl.hp.com>
In message <20021211010512.GA5853@bougret.hpl.hp.com> you write:
> Hi,
Hi Jean!
Thanks for the report.
> Debian Boot :
> -----------
> o Din't pick up new modutils in the init scripts. Probably
> because I used install option 1b in README (/usr/local/sbin).
> o Re-install with option 1a (/sbin), works fine.
> o Maybe this needs to be in README.
Debian have picked up the module-init-tools, so although they're a bit
lagged as I type this, I expect this to become a less common occurrance.
> hp100 (my Ethernet card) :
> ------------------------
> o When loading, module options (various hp100_XXX) are
> ignored, however they are necessary to get the card up and
> running. So, no network :-(
> o Seems that the section handling "param" support in the
> kernel is #if 0, so probably not finished up yet. I see that it's on
> your TODO list.
No, it's finished, it's just not merged 8(. Testers welcome! See:
http://www.kernel.org/pub/linux/kernel/people/rusty/modules/2.5.51.patches.gz
> Pcmcia and airo_cs :
> ------------------
> o Loads with error below, airo_cs driver is functional.
> o i82365 cannot be unloaded, it's unsafe.
> o removal of airo_cs : "Uninitialised timer!/nThis is a
> warning. Your computer is OK". Call trace on demand. Also, the module
> airo not removed (probably due to problem with airo_cs).
That, in itself, should be harmless.
> o re-insertion of the card : nothing happens. No messages.
> o After reboot, /etc/init.d/pcmcia stop -> same thing + script
> hang + a few [kmodule1? <defunct>]. This prevent the computer to
> reboot or shutdown properly (== fsck at next boot).
Wierd. The PCMCIA scripts make assumptions about layout of
/lib/modules/`uname -r` which was broken by the removal of the
directory hierarchy. It's not the only thing (mkinitrd also wants
this). While relying on the layout of the kernel source tree is
broken, no better alternatives have some up, so this is queued to be
reverted once I test that it doesn't break the current tools (which
*should* handle it).
There is a known bug where an *old* rmmod will hang (it has the effect
of "rmmod --wait": I have a patch to differentiate the two
effectively, but it requires everyone to upgrade to 0.9 or above,
which they have probably done by now).
> o af_irda, irda-usb & irtty-sir are "unsafe". I tracked that
> down to the use of MOD_INC_USE_COUNT. The header file module.h give
> hints on how I should convert that to the new world (use
> try_module_get), however your FAQ seems to say something else (just
> remove them, they are useless). I'm quite confused, because those
> MOD_INC_USE_COUNT have a definite purpose... I would appreciate more
> guidance.
Looking at these files:
idra-usb.c: add "netdev->owner = THIS_MODULE;" and get rid of the
MOD_INC_USE_COUNT.
irtty-sir.c: The ldisc code needs an owner field, and it needs to use
it. Until then, this warning is best left where it is.
af_irda: The caller needs to do something here, too. Dave?
> o When/if I will understand what's the best course of action,
> I can fix those myself.
Well, you can rmmod -f in the meantime.
> o Also, maybe you should put a pointer to your FAQ in the
> usual places (like in the README of module-init-tools-0.9.3), because
> it's only because I knew it existed that I've found it.
Hmm the contents of the FAQ are still in flux, which is why it's not
published. The init stuff is still up for debate.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: Linux 2.5.51
From: Eric W. Biederman @ 2002-12-11 9:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: James Simmons, Stian Jordet, Allan Duncan, linux-kernel
In-Reply-To: <1039547936.538.5.camel@zion>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2002-12-10 at 19:16, James Simmons wrote:
> >
> > > > I can take care of radeon's. Did you already used my updated version
> > > > from the PPC tree ?
> > >
> > > Will the Radeon fbdev driver work with all Radeons (for instance a
> > > Radeon 9700 Pro)?
> >
> > Yes I saw support for this card :-)
>
> Well, I'm not sure it quite works yet. Maybe unaccelerated, but anyway,
> my version of radeonfb for 2.5 isn't accelerated yet anyway. I'll work
> on that (or Ani will) now that the API is stable enough.
How well does this driver work if you don't have a firmware
driver initialize the card? aka a pci option ROM.
I am interested because with LinuxBIOS it is still a pain to run
PCI option roms, and I don't necessarily even have then if it a
motherboard with video. There are some embedded/non-x86 platforms
with similar issues.
My primary interest is in the cheap ATI Rage XL chip that is on many
server board. PCI Vendor/device id 1002:4752 (rev 27) from lspci.
If nothing else if some one could point me to some resources on
how to get the appropriate documentation from the video chipset
manufacturers I would be happy.
But I did want to at least point that running a system with out bios
initialized video was certainly among the cases that are used.
Eric
^ 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.