* Re: [PATCH][2.5][CFT] ad1848 PnP updates + fixes
From: Zwane Mwaikambo @ 2002-12-13 11:15 UTC (permalink / raw)
To: Linux Kernel; +Cc: Adam Belay
In-Reply-To: <Pine.LNX.4.50.0212122048590.6931-100000@montezuma.mastecende.com>
Hi Adam,
I had the following hunk from the previous patch to this file, do
we really want to disable that device here?
On Thu, 12 Dec 2002, Zwane Mwaikambo wrote:
> #ifdef CONFIG_PNP
> - if(ad1848_dev){
> - if(audio_activated)
> - pnp_disable_dev(ad1848_dev);
> - put_device(&ad1848_dev->dev);
> +{
> + ad1848_info *p;
> +
> + if (audio_activated == 0)
> + return;
> +
> + while (--nr_ad1848_devs >= 0) {
> + p = &adev_info[nr_ad1848_devs];
> + pnp_disable_dev(p->pnp_dev); /* XXX Should this be done here? */
> + put_device(&p->pnp_dev->dev);
> }
> + pnp_unregister_driver(&ad1848_driver);
> +}
> #endif
--
function.linuxpower.ca
^ permalink raw reply
* RE: [PATCH] Add CONFIG_ACPI_RELAXED_AML option
From: Herbert Nachtnebel @ 2002-12-13 10:55 UTC (permalink / raw)
To: Alan Cox; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
>
> Allocating 1 byte of slack, giving a loud warning about the
> problem and
> erroring if we exceed the 1 byte of slack doesn't sound so bad though?
>
Sure, that's an option. But look at the presented "fix".
Just ignoring the error is plain wrong.
Herbert.
-------------------------------------------------------
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:OT Is this going to be true ?
From: szonyi calin @ 2002-12-13 10:56 UTC (permalink / raw)
To: hps, linux-kernel
In-Reply-To: <ata31a$fhc$1@forge.intermeta.de>
--- "Henning P. Schmiedehausen" <hps@intermeta.de> a écrit : >
Billy Harvey <Billy.Harvey@thrillseeker.net> writes:
> Please read the FAQ at http://www.tux.org/lkml/
Please ...
=====
--
A mouse is a device used to point at
the xterm you want to type in.
Kim Alm on a.s.r.
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] 2.4.20-rmap15b - compile failure
From: Eyal Lebedinsky @ 2002-12-13 10:55 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50L.0212122349520.17748-100000@imladris.surriel.com>
I had a failure building NVIDIA_kernel/nv.c (the nvidia driver):
http://download.nvidia.com/XFree86_40/1.0-4191/NVIDIA_kernel-1.0-4191.tar.gz
It uses
pte = *pte_offset(pg_mid_dir, address);
but this patch removes pte_offset().
1) what is the correct fix (use pte_offset_kernel?)?
2) in general, is it wise to remove pte_offset() or should it
be left for compatability?
I should clearly say that I am not familiar with the workings of this
patch, but find that it is likely to break drivers that are not in
the kernel tree (assuming you patch them).
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
^ permalink raw reply
* Re: 2.5.51 ide module problem (fwd)
From: Alan Cox @ 2002-12-13 10:42 UTC (permalink / raw)
To: Rusty Russell
Cc: Jeff Chua, Adam J. Richter, Linux Kernel Mailing List,
Linus Torvalds, axboe, linux-ide, Patrick Mochel
In-Reply-To: <20021213013637.4F2652C0ED@lists.samba.org>
On Fri, 2002-12-13 at 01:35, Rusty Russell wrote:
> Also, my stress_modules script gave the following warning then oops
> from ide-cd on 2.5.51 SMP x86 (IDE is built-in):
Yes. This mysteriously stsrted happening. I don't know if its now
trapping a long standing IDE bug or its of the other changes people did
to IDE to make it actually follow the devices model properly. I've got a
slightly similar looking 2.4 bug to chase down which makes me suspect
the former.
^ permalink raw reply
* Re: File still being accessed?
From: mdew @ 2002-12-13 10:43 UTC (permalink / raw)
To: alexander.riesen; +Cc: Linux Kernel
In-Reply-To: <20021212113738.GB1647@riesen-pc.gr05.synopsys.com>
On Fri, 2002-12-13 at 00:37, Alex Riesen wrote:
> mdew, Thu, Dec 12, 2002 11:50:19 +0100:
> > > > Under Linux 2.5.51 Ive noticed that Downloader4X (Getright-type for
> > > > linux) http://www.krasu.ru/soft/chuchelo/
> > > >
> > > > when trying to resume a file, It thinks the file is still being
> > > > accessed, however under 2.4, it has no such problem. Is this a bug in
> > > > 2.5.x still? any patches available that could help?
> > > which d4x version, what _exactly_ the message states?
> > > -alex
> > I've tried both D4X GTK2 (2.4.0-rc1) based and GTK1.2.x (1.3.0) based, same results.
> >
> > I add a download, let it partially download, then press
> > "Continue/Restart Downloads"
> >
> > -> Retry 1 ...
> > -> Trying to connect...
> > -> Socket was opened!
> > -> Trying to create a file
> > + File was created!
> > !! File is already opened by another download!
> > !! Downloading was failed...
>
> The problem is advisory file locking. I'll try to debug
> it later, but something changed in how
> fcntl(fd, F_SETLK,{...,F_WRLCK,...}) works. It return an
> error now. Or maybe d4x just fails to unlock it, it doesn't
> check if unlock failed.
> The program doesn't show the real value of errno, just
> handles EINVAL and ENOLCK, so exact analisys is not possible
> apart something bad happened ("is already opened").
> The EINTR case, for instance, would cause similar behaviour.
>
> I suppose d4x just incorrectly uses it, but cannot say anything
> for sure.
> The maintainer is notified.
>
> -alex
email me, whenever its solved ;) other than that, I've found 2.5.51
pretty stable..its getting there.
many thanks
-mdew
^ permalink raw reply
* Re: atyfb in 2.5.51
From: Alan Cox @ 2002-12-13 10:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S. Miller, James Simmons, Benjamin Herrenschmidt,
Paul Mackerras, Linux Kernel Mailing List,
Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0212130949450.6939-100000@vervain.sonytel.be>
On Fri, 2002-12-13 at 08:53, Geert Uytterhoeven wrote:
> (At first I thought you meant an instruction where the opcode crosses those
> two memory types, but we don't put code in video RAM...)
I did. The frame buffer drivers support mmap(). x86 has no "non-exec"
bit. So any user able to open /dev/fb can bring down such a box. Similar
things apply with early athlon and prefetching /dev/fb
^ permalink raw reply
* Re: [resend] mixer controls for bass/treble in emu10k driver
From: Takashi Iwai @ 2002-12-13 10:25 UTC (permalink / raw)
To: jordan.breeding; +Cc: alsa-devel
In-Reply-To: <20021212191706.2A97814B06@Cantor.suse.de>
At Thu, 12 Dec 2002 19:17:02 +0000,
jordan.breeding@attbi.com wrote:
>
>
> > At Thu, 12 Dec 2002 17:55:37 +0000,
> > jordan.breeding@attbi.com wrote:
> > >
> > >
> > > > At Thu, 12 Dec 2002 17:45:00 +0000,
> > > > jordan.breeding@attbi.com wrote:
> > > > >
> > > > > Is it possible for the emu10k (SBLive!/Audigy) driver to get bass/treble
> > > > > mixer controls in ALSA like it has in Windows and the OSS Linux (when you
> > load
> > > > > the right file with the emu10k tools) driver? Thanks.
> > > >
> > > > yes. you need to turn on "Tone Control" switch, then bass and treble
> > > > volumes will respond.
> > > >
> > > >
> > > > ciao,
> > > >
> > > > Takashi
> > >
> > > Thanks for the response. I normally compile ALSA and the driver
> > > itself directly into my 2.5.x kernel, do you happen to know which
> > > source file I need to edit to enable tone control? Thanks.
> >
> > well, i meant to turn on via alsamixer program...
> > you don't have to recompile the driver.
> >
> >
> > Takashi
>
> Is there no way to make the treble/bass tone controls also available
> to OSS mixer programs such as aumix? Thanks.
the bass/treble volumes are mapped onto OSS mixer elements. hence
once if you enabled the tone control, then you can change the values.
you can use amixer to toggle the tone control without gui, and use
alsactl to save/restore the status.
Takashi
-------------------------------------------------------
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: another seagate for the black-list?
From: Måns Rullgård @ 2002-12-13 10:25 UTC (permalink / raw)
To: Aryix; +Cc: linux-kernel
In-Reply-To: <courier.3DF9A5BB.00000AD0@softhome.net>
Aryix <aryix@softhome.net> writes:
> hdparm say: max udma capable 2
> the disk is udma5
Which kernel version and IDE controller do you use? The Promise
driver in 2.4.19 (at least) has a bug preventing anything above UMDA2.
The problem is that hwif->udma_four needs to be set to 1 in some init
function, I don't remember the name. Would someone care to fix it?
--
Måns Rullgård
mru@users.sf.net
^ permalink raw reply
* Re: kernel: matrox fb - missing files, doesn't compile
From: Petr Vandrovec @ 2002-12-13 10:09 UTC (permalink / raw)
To: Ariel; +Cc: linux-fbdev-devel
On 13 Dec 02 at 1:13, Ariel wrote:
> Kernel 2.5.51.
>
> I tried copying the fbcon*.h files from 2.2.19 kernel, but that didn't
> help much.
Either go for 2.5.50, or you'll have to wait several weeks. After looking
at current kernel interface it looks like that I'll have to write
matroxcon to get at least same level of functionality which was
available before, and it will definitely take weeks, or maybe months.
Current interface just supports only cfb, and only very bad for my needs.
And because of matroxfb supports also other modes (such as native text
mode, or loading font into accelerator), bye-bye. For now I recommend you
either to not upgrade, or use vesafb. Besides that accel_putcs() does not
call fb_sync when using font width which is not multiple of 8, and that
with fonts greater than 16*16 pixels (I believe that such fonts are still
supported...) it will corrupt memory...
You can also try to use complete drivers/video, include/video, plus
some of drivers/char and include/linux from 2.5.50... You should be
able to get working system that way too.
Petr Vandrovec
vandrove@vc.cvut.cz
-------------------------------------------------------
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: 2.4.20-ac1 KT400 AGP support
From: BoehmeSilvio @ 2002-12-13 10:18 UTC (permalink / raw)
To: 'Dave Jones'; +Cc: linux-kernel
Hi !
I don't need the AGP 8X mode, but is it possible,
to get this setup running in whatever agp mode ?
Currently it is only possible to start X with VESA support,
because all other drivers need agpgart.
By
Silvio
-----Ursprüngliche Nachricht-----
Von: Dave Jones [mailto:davej@codemonkey.org.uk]
Gesendet: Donnerstag, 12. Dezember 2002 20:21
An: BoehmeSilvio
Cc: linux-kernel@vger.kernel.org
Betreff: Re: 2.4.20-ac1 KT400 AGP support
On Thu, Dec 12, 2002 at 07:04:02PM +0100, BoehmeSilvio wrote:
> Hi !
>
> Hopefully I'm right here.....
>
> I have some trouble to get agpgart working in kernel 2.4.20-ac1.
>
> My setup:
> - ASUS A7V8X with VIA KT400 Chip (AGP 8X)
> - ATI Radeon 9700 PRO (also AGP 8X)
>
> The original 2.4.20 kernel doesn't know this chipset, so I tried the
> 2.4.20-ac1, which has some patches for the KT400.
>
> With 2.4.20-ac1 I get the following error:
>
> agpgart: Maximum main memory to use for agp memory: 690M
> agpgart: Detected Via Apollo KT-400 chipset
> agpgart: unable to determine aperture size
Currently AGPGART doesn't support AGP 3.0 (which is needed for X8 mode)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: 2.5.5[01]]: Xircom Cardbus broken (PCI resource collisions)
From: Arjan van de Ven @ 2002-12-13 10:10 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Alessandro Suardi, linux-kernel
In-Reply-To: <200212122247.gBCMlHgY011021@turing-police.cc.vt.edu>
On Thu, 2002-12-12 at 23:47, Valdis.Kletnieks@vt.edu wrote:
> Been there. Done that. Does the attached patch help? It did for me.
>
> /Valdis
>
>
> ----
>
> --- drivers/pcmcia/cardbus.c.dist 2002-12-03 01:49:29.000000000 -0500
> +++ drivers/pcmcia/cardbus.c 2002-12-03 01:50:23.000000000 -0500
> @@ -283,8 +283,6 @@
> dev->hdr_type = hdr & 0x7f;
>
> pci_setup_device(dev);
> - if (pci_enable_device(dev))
> - continue;
>
> strcpy(dev->dev.bus_id, dev->slot_name);
>
> @@ -302,6 +300,8 @@
> pci_writeb(dev, PCI_INTERRUPT_LINE, irq);
> }
>
> + if (pci_enable_device(dev))
> + continue;
> device_register(&dev->dev);
> pci_insert_device(dev, bus);
> }
interesting. BUT aren't we writing to the device 3 lines before where
you add the pci_enable_device()? That sounds like a bad plan to me ;(
^ permalink raw reply
* RE: Query.... redirecting traffic
From: Paul Gibson @ 2002-12-13 9:57 UTC (permalink / raw)
To: 'Netfilter'
In-Reply-To: <1039772820.15363.4.camel@sander>
Wow
Thanks very much for all the replies..... and examples too :)
Looks like I can get rid of the dodgy redir.
thanks again! :)
-----Original Message-----
From: Sander Sneekes [mailto:sander@dmdsecure.com]
Sent: Friday, 13 December 2002 8:47 PM
To: paul.gibson@subspace.net.au
Cc: Netfilter
Subject: Re: Query.... redirecting traffic
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
iptables -A FORWARD -p tcp --dport 80 -d 192.168.1.1 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp --dport 80 -d 10.10.10.10 -j DNAT
--to
192.168.1.1:12345
On Fri, 2002-12-13 at 10:02, Paul Gibson wrote:
> Hello,
>
> I am wondering if netfilter can do the following.....
>
> http connection comes in on 10.10.10.10 port 80, can iptables then
redirect
> this to go to 192.168.1.1 port 12345 & also allow the returning data to go
> back the opposite way ???
>
> We are currently using "redir" to do it and are having some porblems with
it
> due to an application we run.
>
> TIA
>
> Paul.
--
Sander Sneekes
sander@dmdsecure.com
--
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Thierry Vignaud @ 2002-12-13 9:53 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Friedrich Ewaldt, alsa-user, alsa-devel
In-Reply-To: <s5h3cp3uorz.wl@alsa2.suse.de>
Takashi Iwai <tiwai@suse.de> writes:
> > Mandrake Control Center recognices the card as follows (partly in
> > german, sorry, but perhaps that's no problem in ERL/NUE ;-) ):
> >
> > Hersteller: Fortemedia, Inc
> > Bus: PCI
> > Bus: 1319:801:1319:1319
> > Standort auf den Bus: 0:b:0
> > Beschreibung: Xwave QS3000A [FM801]
> > Modul: snd-fm801
> > Medienklasse: MULTIMEDIA_AUDIO
this information came frome harddrake which uses libldetect (which is
also used by lspcidrake).
bus is vendor_id:card_id:subvendor_id:subcard_id
bus position (Standort auf den Bus) is pci_bus:pci_device:pci_function
Beschreibung is of course description of the device and Hersteller is
vendor
module is of course kernel module
the driver association is made by libldetect from
/usr/share/ldetect-lst/pcitable :
tv@vador ~ $ fgrep fm801 /usr/share/ldetect-lst/pcitable
0x1319 0x0801 "snd-fm801" "Fortemedia, Inc|Xwave QS3000A [FM801]"
0x1319 0x1000 "snd-fm801" "Fortemedia, Inc|FM801 PCI Audio"
> > I had no alsa installed while running hardware detection.
alsa drivers're included in mandrake kernel
> you can check this also via lspci command.
lspcidrake -v will give him the module too
> in the output of lspci in your last mail, the i/o ports and irq are
> missing. please check again?
in order to have the full information, i would like Friedrich to send
us the following information (what i call the classic bug sound
tester) :
"lspcidrake -v | fgrep AUDIO" will tell you which driver your card use
by default
"grep snd-slot /etc/modules.conf" will tell you what driver it
currently uses
"/sbin/lsmod" will enable you to check if its module (driver) is
loaded or not
"/sbin/chkconfig --list sound" and "/sbin/chkconfig --list alsa" will
tell you if sound and alsa services're configured to be run on
initlevel 3
"aumix -q" will tell you if the sound volume is muted or not
"/sbin/fuser -v /dev/dsp" will tell which program uses the sound card.
this will tell us at which stage the problem happen
-------------------------------------------------------
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: dmfs for 2.5.51
From: Joe Thornber @ 2002-12-13 9:58 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, lvm-devel, linux-kernel
In-Reply-To: <20021213052551.GB25099@kroah.com>
On Thu, Dec 12, 2002 at 09:25:51PM -0800, Greg KH wrote:
> On Thu, Dec 12, 2002 at 05:50:01PM -0800, Andrew Morton wrote:
> > 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.
Greg, I didn't mean to make it sound like I was shooting you down, I
just said that we'd leave it as it was for now. Having written the
code I wanted a bit more feedback. When I started writing the fs
interface a couple of people expressed concerns that I should try and
map things properly onto fs semantics and not just create a single
file. Given Andrews comment I guess I haven't done a good job. Could
you flesh out your single file idea a bit more please, there's a lot
of functionality to shoe horn in there.
> > > ...
> > > + 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 :)
y, the dm targets have always accepted their arguments as ascii
strings. So the file system interface just adds code to split the
input into lines, and then sscanf the first three elements of the line
- this is probably less code than the marshalling of binary data that
is done in the ioctl interface.
I see the fact that we're using ascii data as being the big advantage
of the fs interface, which neccessarily means doing a small amount of
parsing in kernel. You can't have things both ways.
> > > ...
> > > +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.
My fault :(
> Nice catch. I'm not sure that the find_page(), __io() and friends
> functions are really needed at all.
It would be nice to get rid of them, what shall we replace them with ?
- Joe
^ permalink raw reply
* Memory Manager Subsystem
From: Alexandre Pires @ 2002-12-13 10:56 UTC (permalink / raw)
To: linux-kernel
Dear Sir,
Somebody could indicate me some material about Memory Manager subsystem and
Memory Map ?
Many thanks in advance.
Alexandre R. Pires
Brasil
_______________________________________________________________________
Yahoo! Encontros
O lugar certo para encontrar a sua alma gêmea.
http://br.encontros.yahoo.com/
^ permalink raw reply
* Re: mcc support on mpc8260
From: Ing.Gianfranco Morandi @ 2002-12-13 9:47 UTC (permalink / raw)
To: Omanakuttan, linuxppc-embedded
In-Reply-To: <3DF8BC91.3010104@tataelxsi.co.in>
I have promised to Pete of releasing some code for such driver. We will
provide to perform such task during the next days.
Actually we are writing some documents to better describe the driver and how
to lock it to the kernel tree.
We will inform the community when the driver will be available.
Anyway on the Motorola site, You can find some example on how program the
mcc.
Be aware do not use the mcc with the silicon revision older than B.1.
Regards
Gianfranco
----- Original Message -----
From: "Omanakuttan" <omanakuttan@tataelxsi.co.in>
To: <linuxppc-embedded@lists.linuxppc.org>
Sent: Thursday, December 12, 2002 5:42 PM
Subject: mcc support on mpc8260
>
> Hi,
> We are developing device drivers for E1/T1 (8 channels) and E3/T3 framer
> chipset (XRT84L38 and XRT7250 ) on mpc8260.
> I don't find any documents on mcc programming for E1/T1. The linux
> kernel lacks support for that too. (At least I could not find any in the
> 2.4.17 kernel)
> for E3/T3, we could find some sample code. But helpless in E1/T1.
>
> Any pointers are welcome.
> Om.
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Query.... redirecting traffic
From: Sander Sneekes @ 2002-12-13 9:47 UTC (permalink / raw)
To: paul.gibson; +Cc: Netfilter
In-Reply-To: <008401c2a286$4cd80ca0$0501a8c0@gndn.subspace.au.com>
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
iptables -A FORWARD -p tcp --dport 80 -d 192.168.1.1 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp --dport 80 -d 10.10.10.10 -j DNAT
--to
192.168.1.1:12345
On Fri, 2002-12-13 at 10:02, Paul Gibson wrote:
> Hello,
>
> I am wondering if netfilter can do the following.....
>
> http connection comes in on 10.10.10.10 port 80, can iptables then redirect
> this to go to 192.168.1.1 port 12345 & also allow the returning data to go
> back the opposite way ???
>
> We are currently using "redir" to do it and are having some porblems with it
> due to an application we run.
>
> TIA
>
> Paul.
--
Sander Sneekes
sander@dmdsecure.com
--
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
^ permalink raw reply
* Re: 2.5.51 ide module problem
From: Alan Cox @ 2002-12-13 10:31 UTC (permalink / raw)
To: Adam J. Richter; +Cc: Jeff Chua, Linux Kernel Mailing List, rusty
In-Reply-To: <20021212235934.A770@baldur.yggdrasil.com>
On Fri, 2002-12-13 at 07:59, Adam J. Richter wrote:
> --- linux-2.5.51/drivers/pci/pci.c 2002-12-09 18:45:52.000000000 -0800
> +++ linux/drivers/pci/pci.c 2002-12-09 19:03:18.000000000 -0800
> @@ -736,6 +736,7 @@
> EXPORT_SYMBOL(isa_bridge);
> #endif
>
> +EXPORT_SYMBOL(pci_enable_device_bars);
> EXPORT_SYMBOL(pci_enable_device);
> EXPORT_SYMBOL(pci_disable_device);
> EXPORT_SYMBOL(pci_max_busnr);
This one looks correct.
> diff -r -u linux-2.5.51/drivers/ide/Kconfig linux/drivers/ide/Kconfig
> --- linux-2.5.51/drivers/ide/Kconfig 2002-12-09 18:45:56.000000000 -0800
> +++ linux/drivers/ide/Kconfig 2002-11-27 18:23:46.000000000 -0800
> @@ -199,7 +199,7 @@
> depends on BLK_DEV_IDE
>
> config BLK_DEV_CMD640
> - bool "CMD640 chipset bugfix/support"
> + tristate "CMD640 chipset bugfix/support"
Please don't do this. You can't "load" the workaround meaningfully for
this device
> config BLK_DEV_GENERIC
> - bool "Generic PCI IDE Chipset Support"
> + tristate "Generic PCI IDE Chipset Support"
> depends on PCI && BLK_DEV_IDEPCI
Probably ok. I need to review that.
> -obj-$(CONFIG_BLK_DEV_IDE) += ide-io.o ide-probe.o ide-geometry.o ide-iops.o ide-taskfile.o ide.o ide-lib.o
> +obj-$(CONFIG_BLK_DEV_IDE) += ide-mod.o
> +ide-mod-objs += ide-io.o ide-probe.o ide-geometry.o ide-iops.o ide-taskfile.o ide.o ide-lib.o
Looks ok
> diff -r -u linux-2.5.51/drivers/ide/pci/cmd640.c linux/drivers/ide/pci/cmd640.c
> --- linux-2.5.51/drivers/ide/pci/cmd640.c 2002-12-09 18:46:22.000000000 -0800
> +++ linux/drivers/ide/pci/cmd640.c 2002-11-27 18:24:00.000000000 -0800
> @@ -102,6 +102,7 @@
No (as per comment above)
> --- linux-2.5.51/drivers/ide/ide-probe.c 2002-12-09 18:46:10.000000000 -0800
> +++ linux/drivers/ide/ide-probe.c 2002-12-12 23:50:58.000000000 -0800
> @@ -831,7 +831,8 @@
> ide_toggle_bounce(drive, 1);
>
> #ifdef CONFIG_BLK_DEV_IDE_TCQ_DEFAULT
> - HWIF(drive)->ide_dma_queued_on(drive);
> + if (HWIF(drive)->ide_dma_queued_on)
> + HWIF(drive)->ide_dma_queued_on(drive);
Looks right
At a first glance (and its only that), drop out the CMD640 changes and
the rest seems ok. Please check it on a few setups and also non modular
since you've changed the probe bits a little.
Alan
^ permalink raw reply
* AW: [PATCH] Add CONFIG_ACPI_RELAXED_AML option
From: Herbert Nachtnebel @ 2002-12-13 9:30 UTC (permalink / raw)
To: NoZizzing OrDripping, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
That's a really bad idea! This size checks are identented to assure, that important data which accidently follows the buffer can't be overridden by brain dead bios coders. Now you allow buffer overflow injection into linux from the bios!
These are serious bios faults, in my DSDT I had to extend a buffer by 128 bytes to avoid a buffer overflow!
The situation doesn't get better if we ignore such errors. We have to urge the manufacturers to correct the DSDT's. And the best way to do this is to recognise the faults and blame them.
Herbert.
> -----Ursprüngliche Nachricht-----
> Von: NoZizzing OrDripping [mailto:nozizzingordripping-/E1597aS9LQAvxtiuMwx3w@public.gmane.org]
> Gesendet: Freitag, 13. Dezember 2002 05:48
> An: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Betreff: [ACPI] [PATCH] Add CONFIG_ACPI_RELAXED_AML option
>
>
> The patch adds a new configuration option,
> CONFIG_ACPI_RELAXED_AML. When turned on,
> the ACPI code will become forgiving of minor
> errors in the AML code.
>
> For this first cut, the patch and option will ignore
> region size errors. An off-by-one error is often
> found in the AML shipped with Toshiba laptops,
> even new models. This minor error prevents the
> AC module from operating without this patch.
>
> I urge the adoption of this patch (or something
> similar) into the ACPI code. This will make it
> much easier to install and proliferate Linux on
> a large category of laptops.
>
> Rick Richardson
> rickr-EySxSuIQeMUAvxtiuMwx3w@public.gmane.org
> [Sorry, have to use my Yahoo account to post to this list)
>
> __________________________________________________
> 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: dmfs for 2.5.51
From: Joe Thornber @ 2002-12-13 9:37 UTC (permalink / raw)
To: Greg KH; +Cc: lvm-devel, linux-kernel
In-Reply-To: <20021213012618.GH23509@kroah.com>
Greg,
On Thu, Dec 12, 2002 at 05:26:19PM -0800, Greg KH wrote:
> Here's a patch against 2.5.51 with a updated dmfs.
I've split out your two changes into seperate patches (patches 21 and
22) and made them available here:
http://people.sistina.com/~thornber/patches/2.5-unstable/2.5.51/2.5.51-dmfs-1/
> with the following modifications:
> - fixed compile time warnings with the dbg() macro (something
> better should be used here, I just commented it out...)
I'm not seeing any warnings, which compiler version are you using ?
> - changed the dev file to print out the kdev value, not be the
> actual block device.
Should we really be exporting a kdev_t to userland, why not just print out
<major>:<minor>
?
> With regards to the last change, I didn't follow the way the other files
> operate with their complex page creation structure, as this is only a
> simple one line file. If the lvm developers want me to change this, I
> will.
What you've done looks fine to me, though allocating a whole page to
hold a single number seems overkill. Why don't you just snprintf into
a char[] held on the stack ?
> If not, I would argue that a number of the other files created
> should be changed to use this simpler format. Or is there some reason
> for creating these lists of pages that I'm missing?
The files can be larger than a single page, which complicates things
somewhat.
- Joe
^ permalink raw reply
* Re: slram and buffer cache
From: Tobias Otto-Adamczak @ 2002-12-13 9:54 UTC (permalink / raw)
To: linux-mtd; +Cc: Jochen Schaeuble
In-Reply-To: <20021212202814.GB5027@psionic.de>
Jochen Schaeuble, 2002-12-12, 21:28h:
> Hi,
> I haven't used mtdblock for a while now so I'm not absolutely sure if
> this is correct. The "cache_size" of the mtdblock driver is initialized
> with the erasesize specified in the slram driver (0x10000 if you haven't
> changed anything). If you want uncached operation you should set this
> value to
> (*curmtd)->mtdinfo->erasesize = 0x0; (slram.c line 180).
> I had no time to check this but from reading the source I think this is
> correct. Please let me know if this works for you. If so it might be a
> good idea to make this size configurable.
Thanks for your reply. I use the latest version of slram.c from
http://www.linux-mtd.infradead.org/ which you can look at
ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/mtd/drivers/mtd/devices/slram.c
Line 206 says already (*curmtd)->mtdinfo->erasesize = 0x0; I know that
other (older) versions of this file have the value 0x10000 here.
However I have added printk()s to slram_read/slram_write to see when
they are actually called and there is a lot of latency (several seconds)
between writing some bytes into a file and see some slram driver
activity. So there must be another point that I'm missing.
I tried to mount with -o sync and also tuned the bdflush parameters,
both helped a little bit to speed up the write process for cached
buffers, but I definitely want to get rid of the caching at all for my
BB-SRAM.
Any more ideas ?
Regards
Tobias
^ permalink raw reply
* Re: [PATCH] 2.4.20-rmap15b
From: Eyal Lebedinsky @ 2002-12-13 9:25 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50L.0212122349520.17748-100000@imladris.surriel.com>
Rik van Riel wrote:
> The patch is available from:
>
> http://surriel.com/patches/2.4/2.4.20-rmap15b
Again the patch is against -rc4 so a Makefile hunk fails. Not
a real problem.
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
^ permalink raw reply
* Re: [PATCH] "extern inline" to "static inline" allows compile
From: Richard Henderson @ 2002-12-13 9:24 UTC (permalink / raw)
To: Rusty Russell; +Cc: Matt Reppert, linux-kernel
In-Reply-To: <20021213002028.C2CC72C0AB@lists.samba.org>
On Fri, Dec 13, 2002 at 11:18:57AM +1100, Rusty Russell wrote:
> This patch is simple, but not trivial, and since RTH wrote this, I'm
> assuming all those __EXTERN_INLINE's are defined and undefned in
> multiple places for a reason.
Indeed.
> Richard?
Fixed properly by reverting the asm-alpha/pci.h patch
and including asm/io.h in drivers/scsi/sr_ioctl.c.
r~
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Terje Eggestad @ 2002-12-13 9:21 UTC (permalink / raw)
To: J.A. Magallon; +Cc: Mark Mielke, H. Peter Anvin, linux-kernel, Dave Jones
In-Reply-To: <20021212205655.GA1658@werewolf.able.es>
On tor, 2002-12-12 at 21:56, J.A. Magallon wrote:
> On 2002.12.12 Mark Mielke wrote:
> >On Thu, Dec 12, 2002 at 10:42:56AM +0100, Terje Eggestad wrote:
> >> On ons, 2002-12-11 at 19:50, H. Peter Anvin wrote:
> >> > Terje Eggestad wrote:
> >> > > PS: rdtsc on P4 is also painfully slow!!!
> >> > Now that's just braindead...
> >> It takes about 11 cycles on athlon, 34 on PII, and a whooping 84 on P4.
> >> For a simple op like that, even 11 is a lot... Really makes you wonder.
> >
> >Some of this discussion is a little bit unfair. My understanding of what
> >Intel has done with the P4, is create an architecture that allows for
> >higher clock rates. Sure the P4 might take 84, vs PII 34, but how many
> >PII 2.4 Ghz machines have you ever seen on the market?
> >
> >Certainly, some of their decisions seem to be a little odd on the surface.
> >
> >That doesn't mean the situation is black and white.
> >
>
> No. The situation is just black. Each day Intel processors are a bigger
> pile of crap and less intelligent, but MHz compensate for the average
> office user. Think of what could a P4 do if the same effort put on
> Hz was put on getting cheap a cache of 4Mb or 8Mb like MIPSes have. Or
> closer, 1Mb like G4s.
> If syscalls take 300% time but processor is also 300% faster 'nobody
> notices'.
Well, it does make sense if Intel optimized away rdtsc for more commonly
used things, but even that don't seem to be the case. I'm measuring the
overhead of doing a syscall on Linux (int 80) to be ~280 cycles on PIII,
and Athlon, while it's 1600 cycles on P4.
TJ
--
_________________________________________________________________________
Terje Eggestad mailto:terje.eggestad@scali.no
Scali Scalable Linux Systems http://www.scali.com
Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal +47 975 31 574 (MOBILE)
N-0619 Oslo fax: +47 22 62 89 51
NORWAY
_________________________________________________________________________
^ 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.