* Fix up dma_alloc_coherent with 64bit DMA masks on i386.
From: davej @ 2003-01-08 19:46 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Cset 1.808 in 2.4 never got propagated forward to 2.5
It's pretty much the same fix as below (s/!=/</), but with the following
changes
- This was a patch to pci_alloc_consistant(), which now seems to be
dma_alloc_coherent()
- Removal of the u32 cast
diff -urpN --exclude-from=/home/davej/.exclude bk-linus/arch/i386/kernel/pci-dma.c linux-2.5/arch/i386/kernel/pci-dma.c
--- bk-linus/arch/i386/kernel/pci-dma.c 2003-01-08 10:46:59.000000000 -0100
+++ linux-2.5/arch/i386/kernel/pci-dma.c 2003-01-08 11:02:50.000000000 -0100
@@ -19,7 +19,7 @@ void *dma_alloc_coherent(struct device *
void *ret;
int gfp = GFP_ATOMIC;
- if (dev == NULL || ((u32)*dev->dma_mask != 0xffffffff))
+ if (dev == NULL || (*dev->dma_mask < 0xffffffff))
gfp |= GFP_DMA;
ret = (void *)__get_free_pages(gfp, get_order(size));
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: Andrew McGregor @ 2003-01-08 19:48 UTC (permalink / raw)
To: Wolfgang Fritz, linux-kernel
In-Reply-To: <3E1C4872.7080508@gmx.net>
--On Wednesday, January 08, 2003 16:49:06 +0100 Wolfgang Fritz
<wolfgang.fritz@gmx.net> wrote:
> That is done in the isdn_audio DTMF detection but did not work very well
> with a number of phone sets I tested which seem to generate DTMF tones
> with strong harmonics. They may be out of spec but they exist.
Distortion :-) Unfortunately, this stuff is cheap analog and even harmonic
distortion will create havoc with that algorithm.
By the way, if you happened to be trying this with Quicknet hardware, there
is a major overhaul to the driver coming that reduces the distortion levels
in the analog stages of the hardware immensely. (I suspect not as the
thread is about isdn)
> I have a patch which adds a simple energy comparison and some
> plausablility checks to the DTMF eval code but does not look at the
> harmonics. That improved the detection with above phone sets.
>
> Maybe it would be better to reenable harmonic checks but comparing
> harmonic levels to the level of the fundamental instead of using
> absolute values as in the present implementation.
It certainly would. And be relatively generous about the relative amount
of harmonic allowed; something like 30%. If you use absolute levels,
you're at the mercy of noise and level calibration errors, both of which
you have to assume are present. If you require the relative level to be
too low, you're at the mercy of distortion.
> OTOH I don't think its a good approach to check harmonics anyway but to
> check other non DTMF frequencies in the main speech band and only accept
> a DTMF if a DTMF frequency pair is present but no signal on the non DTMF
> frequencies (no signal = xxx dB below the detected DTMF levels).
>
> There exists a long text about DTMF detection somewhere on the net (I may
> have the link in the office but I'm on vacation now). What I remember is
> that a "correct" DTMF detection requires much more computing power as the
> present i4l implementation needs (much longer audio samples for the
> goertzel filter, a larger number of frequencies to check) and a standard
> test procedure with a lot of test cases which are not available to mortal
> humans (audio tapes from Bellcore IIRC)
There is a pretty good text linked in the source :-)
It's also near the top of a google for goertzel filter dtmf.
What I don't get is why the kernel links to this text, but implements one
of the algorithms that the conclusion of that paper rejects as unable to
satisfy the standard for DTMF detection? Maybe the original implementor
wanted to avoid doing matrix math in the kernel, or couldn't understand
what to do. The best algorithm was only twice as expensive in CPU, for
dramatically better reliability and standards compliance.
Andrew
^ permalink raw reply
* Re:[BUG] cpci patch for kernel 2.4.19 bug
From: Rusty Lynch @ 2003-01-08 19:46 UTC (permalink / raw)
To: greg, harold.yang, scottm; +Cc: linux-kernel, pcihpd-discuss
From: "Yang, Harold" <harold.yang@intel.com>
>
> Hi, Scott & Greg:
>
> I have applied the cpci patch for kernel 2.4.19, and test it
> thoroughly on ZT5084 platform. Two bugs are found:
>
> 1. In my ZT5084, the driver can't correctly detect the cPCI
> Hot Swap bridge device. Two DEC21154 exist on ZT5084,
> however, only one is the right bridge. The driver can't
> distinguish them correctly.
I just got a couple of ZT5541 peripheral master boards
and can finally see what happens when an enumerable board
is plugged into a ZT5084 chassis using a ZT5550 system master
board.
As of yet I have only tried a 2.5.54 kernel, but I see the
same problems along with some other wacky behavior that I
am trying to isolate.
Now about the multiple DEC21154 devices ==> on my ZT5550 that
is in system master mode, the first DEC21154 device is a bridge
for the slots to the left of the system slots, and the second
DEC21154 is a bridge for the right of the system slots.
So if I boot the system master (I'll talk about problems with
hotswaping in another email) with a peripheral board plugged
into one of the slots on the right of the master using the
current 2.5.54 kernel then I run into problems the first time
cpci_hotplug_core.c::check_slots() runs because it only looks
at the first bus when trying to find the card that caused the
#ENUM.
The following patch will register each of the cpci busses instead
of just the first one detected.
NOTE: I'm a little worried that the right way to do this is to
properly initialize the RSS bits, or at least see how the
chassis is configured via the RSS bits to determine which
cpci bus to register. The ZT5084 doesn't have near as many
configurations as newer designs like the ZT5088.
===== cpcihp_zt5550.c 1.1 vs edited =====
--- 1.1/drivers/hotplug/cpcihp_zt5550.c Fri Nov 1 11:48:05 2002
+++ edited/cpcihp_zt5550.c Wed Jan 8 11:17:32 2003
@@ -191,6 +191,7 @@
const struct pci_device_id *ent)
{
int status;
+ struct pci_dev *tmp = 0;
status = zt5550_hc_config(pdev);
if(status != 0) {
@@ -220,20 +221,16 @@
}
dbg("registered controller");
- /* Look for first device matching cPCI bus's bridge vendor and device IDs */
- if(!(bus0_dev = pci_find_device(PCI_VENDOR_ID_DEC,
- PCI_DEVICE_ID_DEC_21154, NULL))) {
- status = -ENODEV;
- goto init_register_error;
- }
- bus0 = bus0_dev->subordinate;
+ while(tmp = pci_find_device(PCI_VENDOR_ID_DEC,
+ PCI_DEVICE_ID_DEC_21154, tmp)) {
+ if(cpci_hp_register_bus(tmp->subordinate, 0x0a, 0x0f)) {
+ err("could not register cPCI hotplug bus #%i",
+ tmp->subordinate);
+ continue;
+ }
- status = cpci_hp_register_bus(bus0, 0x0a, 0x0f);
- if(status != 0) {
- err("could not register cPCI hotplug bus");
- goto init_register_error;
+ dbg("registered bus #%i", tmp->subordinate);
}
- dbg("registered bus");
status = cpci_hp_start();
if(status != 0) {
^ permalink raw reply
* Re: [patch] Use XKPHYS for 64-bit TLB flushes
From: Mike Uhler @ 2003-01-08 19:33 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Dominic Sweetman, Ralf Baechle, linux-mips, uhler
In-Reply-To: <Pine.GSO.3.96.1030108200826.7872A-100000@delta.ds2.pg.gda.pl>
>
> They do are different: KSEG0+entry*0x2000, likewise for XKPHYS -- see the
> patch.
This is precisely what we use for our internal testing (which is also
exported to MIPS32 and MIPS64 architecture licensees) to initialize the
TLB. I have not yet seen a case where this fails, and would be interested
in hearing about any case where it does fail.
/gmu
--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Michael Uhler, VP, Systems, Architecture, and Software Products
MIPS Technologies, Inc. Email: uhler@mips.com Pager: uhler_p@mips.com
1225 Charleston Road Voice: (650)567-5025 FAX: (650)567-5225
Mountain View, CA 94043 Mobile: (650)868-6870 Admin: (650)567-5085
^ permalink raw reply
* Re: tenth post about PCI code, need help
From: Richard B. Johnson @ 2003-01-08 19:44 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel
In-Reply-To: <avhtlu$qr9$1@cesium.transmeta.com>
On 8 Jan 2003, H. Peter Anvin wrote:
> Followup to: <Pine.LNX.3.95.1030108132812.28791A-100000@chaos.analogic.com>
> By author: "Richard B. Johnson" <root@chaos.analogic.com>
> In newsgroup: linux.dev.kernel
> >
> > The problem is that he's discovered something that's not supposed
> > to be in the code. Only 32-bit accesses are supposed to be made to
> > the PCI controller ports. He has discovered that somebody has made
> > some 8-bit accesses that will not become configuration 'transactions'
> > because they are not 32 bits.
> >
>
> Right. That's what the code is checking for.
>
> -hpa
Somebody is very lucky the designer of the bus interface state-machine
let him get away with it. This is a borderline "insane instruction" that
could, on some (future?) machine, require a power-off to recover. This is
NotGood(tm). It's like testing a fuse by shorting out a circuit. If it
works, the circuit no longer works. If I doesn't, the circuit no longer
works. Some things should not be tested.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Re: [patch] Use XKPHYS for 64-bit TLB flushes
From: Mike Uhler @ 2003-01-08 19:33 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Dominic Sweetman, Ralf Baechle, linux-mips, uhler
In-Reply-To: <Pine.GSO.3.96.1030108200826.7872A-100000@delta.ds2.pg.gda.pl>
>
> They do are different: KSEG0+entry*0x2000, likewise for XKPHYS -- see the
> patch.
This is precisely what we use for our internal testing (which is also
exported to MIPS32 and MIPS64 architecture licensees) to initialize the
TLB. I have not yet seen a case where this fails, and would be interested
in hearing about any case where it does fail.
/gmu
--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Michael Uhler, VP, Systems, Architecture, and Software Products
MIPS Technologies, Inc. Email: uhler@mips.com Pager: uhler_p@mips.com
1225 Charleston Road Voice: (650)567-5025 FAX: (650)567-5225
Mountain View, CA 94043 Mobile: (650)868-6870 Admin: (650)567-5085
^ permalink raw reply
* Re: Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)
From: Andre Hedrick @ 2003-01-08 19:37 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Roman Zippel, linux-kernel
In-Reply-To: <20030108174827.A28042@ucw.cz>
On Wed, 8 Jan 2003, Vojtech Pavlik wrote:
> On Tue, Jan 07, 2003 at 02:45:51PM -0800, Andre Hedrick wrote:
>
> > > Andre Hedrick wrote:
> > >
> > > > Please continue to think of TCP checksums as valid for a data transport,
> > > > you data will be gone soon enough.
> > > >
> > > > Initiator == Controller
> > > > Target == Disk
> > > > iSCSI == cable or ribbon
> > > >
> > > > Please turn off the CRC on your disk drive and see if you still have data.
> > >
> > > This maybe works as PR, but otherwise it's crap.
> >
> > So, please turn off the CRC's in your onboard storage today and see how
> > long it lasts.
>
> 1) Bad comparison.
>
> 2) It'd last very very long, because I never get a CRC error anyway.
So turn them off so it never checks, nevermind :-)
--ah
^ permalink raw reply
* Re: Status of linuxppc_2.5
From: Boris Bezlaj @ 2003-01-08 19:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Pantelis Antoniou, linuxppc-dev
In-Reply-To: <1042050862.782.12.camel@zion.wanadoo.fr>
On Wed, Jan 08, 2003 at 07:34:22PM +0100, Benjamin Herrenschmidt wrote:
> >
> > But does the writing work in 2.4.x ? For me it works flawlessly in 2.2.x,
> > but in 2.4 there are some problems with settling (only when writing; read
> > is fine), which im trying to figure out and fix.
>
> Did didn't try that driver very hard lately. Please cc me any fix you
> may have.
None for now..didn't found the problem yet..i will let you know when
(if) i produce a fix.
>
> Note also that there is a darwin driver for swim3 floating around that
> gets a lot of code from MacOS 9 and that appear to document a bunch
> of black magic stuffs, so that may be a good source of information. I
> think it's on mklinux.org
It is..looks tasty too. I will look into it.
--
With best regards,
Boris B.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* RE: [ACPI] RE: kacpidpc needs to die
From: Grover, Andrew @ 2003-01-08 19:24 UTC (permalink / raw)
To: Pavel Machek, ACPI mailing list, kernel list
> From: Grover, Andrew
> > From: Pavel Machek [mailto:pavel-+ZI9xUNit7I@public.gmane.org]
> > For reasons discussed before [forking from timer is not
> safe, anyway],
> > kacpidpc needs to die. Andrew, are you going to kill it or
> should I do
> > it?
>
> I can kill it...let me just verify with you --
> acpi_os_queue_for_execution has a two block switch statement, just use
> the first block (the case that uses schedule_work) and delete
> the rest,
> yes?
Oops, and combine acpi_os_schedule_exec and acpi_os_queue_exec, so that
we call dpc->function() from the original thread. Anything else?
-- Andy
^ permalink raw reply
* Re: 405LP - Beech with SSX firmware
From: Hollis Blanchard @ 2003-01-08 19:23 UTC (permalink / raw)
To: embedded list
In-Reply-To: <1040427361.1096.27.camel@granite.austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
On Fri, 2002-12-20 at 17:36, Hollis Blanchard wrote:
> Hi, this patch (copied from Arctic) allows Beech to boot with SSX
> firmware. If there's a way to detect OpenBIOS vs PIBS (I've asked for
> confirmation) then I think the Beech and Arctic ifdefs could be combined
> in the file. There may not be though, and in the meantime this works.
There is currently no way to detect PIBS, though I think I talked the
developer into including "PIBS" string in the future.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
[-- Attachment #2: 405LP-beech-ssx.diff --]
[-- Type: text/plain, Size: 1293 bytes --]
===== arch/ppc/boot/simple/embed_config.c 1.20 vs edited =====
--- 1.20/arch/ppc/boot/simple/embed_config.c Sun Dec 15 20:02:08 2002
+++ edited/arch/ppc/boot/simple/embed_config.c Wed Dec 18 15:53:18 2002
@@ -868,12 +868,33 @@
#endif
#ifdef CONFIG_BEECH
-static void
-get_board_info(bd_t **bdp)
+/* Several bootloaders have been used on Beech. We assume either
+ * SSX or OpenBIOS */
+
+#define SSX_BIOS_ADDR 0xFFFF0000
+#define SSX_BIOS_GET_BOARD_INFO 0
+
+struct ssx_bios_id {
+ unsigned int boot_branch; /* Branch to bootcode */
+ char ssx_bios[8]; /* "SSX BIOS" (no \0) */
+ void (*bios_entry_point)(unsigned int, bd_t *); /* Call bios_entry_point(cmd, &data) */
+};
+
+extern int memcmp(const void *s1, const void *s2, size_t n);
+
+static void get_board_info(bd_t **bdp)
{
- typedef void (*PFV)(bd_t *bd);
- ((PFV)(*(unsigned long *)BOARD_INFO_VECTOR))(*bdp);
- return;
+ struct ssx_bios_id *ssx = (struct ssx_bios_id *)SSX_BIOS_ADDR;
+
+ /* Check for SSX signature */
+
+ if (memcmp(&ssx->ssx_bios, "SSX BIOS", 8) == 0) {
+ ssx->bios_entry_point(SSX_BIOS_GET_BOARD_INFO, *bdp);
+ } else {
+ /* It's not SSX, so assume OpenBIOS */
+ typedef void (*PFV)(bd_t *bd);
+ ((PFV)(*(unsigned long *)BOARD_INFO_VECTOR))(*bdp);
+ }
}
void
^ permalink raw reply
* RE: [ACPI] RE: kacpidpc needs to die
From: Grover, Andrew @ 2003-01-08 19:24 UTC (permalink / raw)
To: Pavel Machek, ACPI mailing list, kernel list
> From: Grover, Andrew
> > From: Pavel Machek [mailto:pavel@ucw.cz]
> > For reasons discussed before [forking from timer is not
> safe, anyway],
> > kacpidpc needs to die. Andrew, are you going to kill it or
> should I do
> > it?
>
> I can kill it...let me just verify with you --
> acpi_os_queue_for_execution has a two block switch statement, just use
> the first block (the case that uses schedule_work) and delete
> the rest,
> yes?
Oops, and combine acpi_os_schedule_exec and acpi_os_queue_exec, so that
we call dpc->function() from the original thread. Anything else?
-- Andy
^ permalink raw reply
* [BK FBDEV updates]
From: James Simmons @ 2003-01-08 19:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Fbdev development list, Linux Kernel Mailing List
Linus, please do a
bk pull http://fbdev.bkbits.net:8080/fbdev-2.5
This will update the following files:
include/video/font.h | 24
arch/m68k/kernel/m68k_defs.c | 2
drivers/video/Kconfig | 2
drivers/video/Makefile | 3
drivers/video/aty/atyfb_base.c | 4
drivers/video/console/Kconfig | 14
drivers/video/console/fbcon.c | 90 +-
drivers/video/console/sticon.c | 101 +-
drivers/video/console/sticore.c | 159 ++--
drivers/video/fbmem.c | 13
drivers/video/fbmon.c | 369 ++++++++++
drivers/video/i810/i810.h | 2
drivers/video/i810/i810_accel.c | 11
drivers/video/i810/i810_dvt.c | 2
drivers/video/i810/i810_main.c | 51 -
drivers/video/i810/i810_main.h | 79 --
drivers/video/riva/Makefile | 2
drivers/video/riva/fbdev.c | 1468 +++++++++++++++++++---------------------
drivers/video/riva/nv_driver.c | 212 +++++
drivers/video/riva/riva_hw.c | 350 +++++++--
drivers/video/riva/rivafb.h | 15
drivers/video/sstfb.c | 711 +++++++++----------
drivers/video/sstfb.h | 31
drivers/video/sticore.h | 58 -
drivers/video/stifb.c | 103 ++
include/linux/fb.h | 4
include/linux/font.h | 30
27 files changed, 2337 insertions(+), 1573 deletions(-)
through these ChangeSets:
<jsimmons@maxwell.earthlink.net> (03/01/08 1.887)
[MONITOR support] GTF support for VESA complaint monitors. Here we calculate the general timings needed so we don't over step the bounds for a monitor.
[fbmem.c cleanup] Name change to make teh code easier to read.
<jsimmons@maxwell.earthlink.net> (03/01/07 1.879.2.95)
Updates from Helge Deller for the console/fbdev drivers for the PARISC platform. Small fix for clearing the screen and a string typo for the Voodoo 1/2 driver.
<jsimmons@maxwell.earthlink.net> (03/01/06 1.879.2.93)
[RIVA FBDEV] Driver now uses its own fb_open and fb_release function again. It has no ill effects. The drivers uses strickly hardware acceleration so we don't need cfb_fillrect and cfb_copyarea.
Cleaned up font.h. Geerts orignal pacth broke them up into a font.h in video and one in linux. Now I put them back together again in include/linux. The m68k platform has been updated for this change.
<jsimmons@maxwell.earthlink.net> (03/01/06 1.879.2.92)
Added resize support for the framebuffer console. Now you can change the console size via stty. Also support for color palette changing on VC switch is supported.
<jsimmons@maxwell.earthlink.net> (03/01/06 1.879.2.91)
I810 fbdev updates. Cursor fix for ati mach 64 cards on big endian machines. Buffer over flow fix for fbcon putcs function. C99 initializers for the STI console drivers.Voodoo 1/2 and NVIDIA driver updates.
The diff is located at
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
^ permalink raw reply
* Re: [patch] Use XKPHYS for 64-bit TLB flushes
From: Maciej W. Rozycki @ 2003-01-08 19:18 UTC (permalink / raw)
To: Dominic Sweetman; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <15900.30127.646847.937900@arsenal.algor.co.uk>
On Wed, 8 Jan 2003, Dominic Sweetman wrote:
> It's probably better to use legal kuseg virtual addresses (but with
I'd wait until there is an implementation that breaks with KSEG0 or
XKPHYS addresses. Hopefully forever.
> the invalid bit set) for initialising TLBs. And to make them all
> different...
They do are different: KSEG0+entry*0x2000, likewise for XKPHYS -- see the
patch.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: [BUG] 2.5.54 sb16.c compile fails
From: Bill Davidsen @ 2003-01-08 19:19 UTC (permalink / raw)
To: Ruslan U. Zakirov; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.BSF.4.05.10301082024220.88742-100000@wildrose.miee.ru>
On Wed, 8 Jan 2003, Ruslan U. Zakirov wrote:
> All this errors relay to new PnP layer implementation.
I'm unfortunately aware, I've been sending up problem reports, and I'm
delighted that someone has responded promptly.
> I've send PATCH to SB16/AWE32 card just now.
> If you have this card, can you test it and send me results?
As soon as I can get a new build. I think that card is still in the
machine, if nbot it can be put there after 5pm.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: tenth post about PCI code, need help
From: H. Peter Anvin @ 2003-01-08 19:20 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.3.95.1030108132812.28791A-100000@chaos.analogic.com>
Followup to: <Pine.LNX.3.95.1030108132812.28791A-100000@chaos.analogic.com>
By author: "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
>
> The problem is that he's discovered something that's not supposed
> to be in the code. Only 32-bit accesses are supposed to be made to
> the PCI controller ports. He has discovered that somebody has made
> some 8-bit accesses that will not become configuration 'transactions'
> because they are not 32 bits.
>
Right. That's what the code is checking for.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* Re: [Lustre-devel] Re: fixing redundant network opens on Linux file creation
From: Peter Braam @ 2003-01-08 19:11 UTC (permalink / raw)
To: Bryan Henderson
Cc: Andreas Dilger, Jan Hudec, linux-fsdevel, linux-fsdevel-owner,
Lustre Development Mailing List, Richard Sharpe, samba-technical,
Mike Shaver, Steven French
In-Reply-To: <OF712DB69E.29692BF5-ON87256CA8.005EDF12-88256CA8.0061FDC2@us.ibm.com>
Hi,
I have no objections to a name change. We are not so religious about
"intent" as a name.
On Wed, Jan 08, 2003 at 10:52:51AM -0700, Bryan Henderson wrote:
> >I don't see where you are coming from here. Could you be more specific on
> >whether you think the entity declaring an "intent" is user-space, the VFS
> >code in fs/*.c, the filesystem driver code in fs/*/*.c or what?
>
> As a general principle, any of those things could declare intent. In the
> Lustre design we're talking about, I don't believe any of them does. Hence
> my objection to the term "intent." Based on that word, I thought at first
> I might just have missed something in the definition of the interface, but
> I don't think so anymore.
>
> >I don't
> >really see where you can "change your mind" in the middle of creating a
> >file, unless there was an error somewhere along the way.
open with O_CREATE | O_EXCL is a good example.
> I don't either. (And apparently, simple errors are no exception in the
> Lustre design). Hence, you have declared significantly more than an intent
> when you did the lookup.
>
> >If you call
> >sys_mkdir() you have declared an "intent" to create a directory
>
> Not as "intent" is usually understood. If you call sys_mkdir(), you have
> commanded the kernel to create the directory. That's a lot different from
> declaring that you intend to create the directory.
>
> I believe the lustre patch works. I also believe it uses the wrong
> terminology, creates an interface to filesystem drivers that is brittle and
> hard to understand, and doesn't solve as wide a range of problems as it
> could. I believe that what it calls a declaration of intent is really a
> declaration of what POSIX system call the caller is in the middle of
> performing.
>
> On the other hand, it has been pointed out that one of its goals was to
> minimize the changes to fs/*.c. I agree the patch is a good way to achieve
> that goal.
>
> If it were my decision, I would solve the Lustre problem, and the Samba
> problem, and some of my own as well, by putting higher level filesystem
> driver interfaces into Linux, such as some other kernels do.
>
> Let the
> filesystem driver do the whole "lookup, create directory, add directory
> entry" operation if it wants to, and in that case make just that one call
> to the filesystem driver and be done. Let the filesystem driver deal with
> the problems of failures halfway through the sequence.
>
> But suggestions I've made to give more power to filesystem drivers have in
> the past met resistance from those who want to keep centralized control and
> maintain uniformity among the various filesystem types).
That proposal has been made by many other people, everywhere. Of
course we could work with that too.
Personally I rather like the Linux VFS because it does locking etc: Al
Viro has made it very clear that e.g. locking for renames, which is
incredibly hard, is best done once (what you call centralized) than
many times by different file systems.
This is the one single reason that we used the "intent" solution: it
can make use of the VFS infrastructure better than high level calls.
But again, I'm not religious about this -- I am religious about
getting correctness for clustering file systems. And we have had to do
some other things (like dealing with dentries in highly non-standard
ways) to get correctness. And of course, we have many problems
left...
- Peter -
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lustre-devel
- Peter -
^ permalink raw reply
* Re: CRAMFS on MTD/NAND Issue
From: Russ Dill @ 2003-01-08 19:42 UTC (permalink / raw)
To: Srinivasu.Vaduguri; +Cc: linux-mtd
In-Reply-To: <F252EE46074AB645B4F44947EEAD5727C83809@mvebe001.americas.nokia.com>
On Wed, 2003-01-08 at 05:40, Srinivasu.Vaduguri@nokia.com wrote:
> Hi all,
>
> I am trying to mount CRAMFS using MTD driver on a NAND flash.
> If there is a BAD block in the CRAMFS area of the NAND flash then i get the following error during mount.
>
> Error -3 while decompressing!
> 802c3674(666163445)->83d7d000(4096)
>
> Then the applications on the mounted cramfs are not running properly.
NAND *will* have bad blocks, cramfs does not handle bad blocks. There
isn't an elegant solution for this right now, but here are some options:
cramfs on top of nftl: This works resonably well, but seems like
overkill to me, and it puts you in questionable legal status if you
aren't using an m-systems product afaik (this is what I use)
yaffs: desgined for NAND, but has no compression
jffs2: The NAND code is pretty new, and the journalling is probably
overkill for your application, but it will work, and should be able to
adapt to bad blocks.
roll your own: Please, make a static compressed filesystem (like cramfs)
that incorporates extra blocks, so that when the checksum is bad while
initially writing the filesystem, or reading the file system (in the
case where ecc can save the data), it rewrites this block to a free
sector). It would seem like a simple modification to cramfs to me.
^ permalink raw reply
* Re: Policy Language
From: Russell Coker @ 2003-01-08 19:10 UTC (permalink / raw)
To: selinux
In-Reply-To: <000a01c2b740$0f11f420$6600a8c0@columbia.tresys.com>
On Wed, 8 Jan 2003 19:02, Frank Mayer wrote:
> I would ask that we only change the policy syntax reluctantly and as
> limited as possible, and only for strong need. Every time the language
> changes, it can be a lot or little work for us to sync up our parser for
> setools. Since we have a requirement to maintain backwards
> compatibility with older policy syntax, each change can be a lot of
> work.
While we're on the topic, I think it would be good if the following files
change as little as possible, and wherever possible the only changes should
be in adding new entries.
access_vectors
initial_sids
security_classes
initial_sid_contexts
Whenever we have a major change to the kernel code it seems to result in a
situation where the policy and the checkpolicy program need to be updated at
the same time. Installing the checkpolicy program first has no drastic
consequences, but installing the new policy first can screw up an existing
kernel.
This is something I still haven't adequately addressed in my Debian packages,
and is probably something that will cause problems for other people who are
preparing SE Linux packages.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [LARTC] Incomprehensive problem with tc filter & mangle...
From: Stef Coene @ 2003-01-08 19:07 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104197594226744@msgid-missing>
> It's always the same thing...
>
> Only the default setting seems to work.
>
> From yesterday, I've tried with match ip src, and this also doesn't work.
> ($TC filter add dev $EXT_IFACE parent 1: protocol ip prio 15 u32 match ip
> src $PREFERED_IP flowid 1:10)
>
> I've tried to use mangle mark to do the same thing, and as every time
> always the default setting seems to work.
>
> I've tried another thing :
> I used some rules from a script found here :
> http://www.linux-france.org/prj/inetdoc/i/net/guides/Advanced-routing-Howto
>/ Advanced-routing-Howto.v0.9-15.html#ss15.8
>
> So I used :
>
> $TC filter add dev $EXT_IFACE parent 1:0 protocol ip prio 10 u32 \
> match ip tos 0x10 0xff flowid 1:10
> $TC filter add dev $EXT_IFACE parent 1:0 protocol ip prio 10 u32 \
> match ip protocol 1 0xff flowid 1:10
> $TC filter add dev $EXT_IFACE parent 1: protocol ip prio 10 u32 \
> match ip protocol 6 0xff \
> match u8 0x05 0x0f at 0 \
> match u16 0x0000 0xffc0 at 2 \
> match u8 0x10 0xff at 33 \
> flowid 1:10
>
> In addition to my own rules.... And these three rules work, not mine.
>
> I really understand anything. What's wrong with my rules ?
I have no idea. What if you try to change to working rules untill you have
the match you want? Maybe you find the error if you test each change.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: tenth post about PCI code, need help
From: Ray Lee @ 2003-01-08 19:13 UTC (permalink / raw)
To: root; +Cc: fretre3618, Linux Kernel
In-Reply-To: <Pine.LNX.3.95.1030108132812.28791A-100000@chaos.analogic.com>
On Wed, 2003-01-08 at 10:49, Richard B. Johnson wrote:
> The problem is that he's discovered something that's not supposed
> to be in the code. Only 32-bit accesses are supposed to be made to
> the PCI controller ports.
<shrug> Okay, I withdraw my interpretation. Since I had to rewrite
arch/ppc/kernel/qspan_pci.c recently, I felt mildly qualified to offer
an opinion, but obviously I was wrong :-).
Ray
^ permalink raw reply
* Re: Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)
From: H. Peter Anvin @ 2003-01-08 19:10 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030107053146.A16578@kerberos.ncsl.nist.gov>
Followup to: <20030107053146.A16578@kerberos.ncsl.nist.gov>
By author: Olivier Galibert <galibert@pobox.com>
In newsgroup: linux.dev.kernel
>
> On Tue, Jan 07, 2003 at 01:39:38PM +1300, Andrew McGregor wrote:
> > Ethernet and TCP were both designed to be cheap to evaluate, not the
> > absolute last word in integrity. There is a move underway to provide an
> > optional stronger TCP digest for IPv6, and if used with that then there is
> > no need for the iSCSI digest. Otherwise, well, play dice with the data.
> > Loaded in your favour, but still dice.
>
> Ethernet's checksum is a standard crc32, with all the usual good
> properties and, at least on FE and lower, 1500bytes max of payload.
> So it's quite reasonable. TCP's checksum, though, is crap.
>
> I'm not entirely sure how crc32 would behave on jumbo frames.
>
AUTODIN-II CRC32 (the one used by Ethernet) is stable up to 11454
bytes. The jumbo frame size was chosen as the largest multiple of the
standard IP payload size to fit within this number.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* Re: [patch] Use XKPHYS for 64-bit TLB flushes
From: Dominic Sweetman @ 2003-01-08 19:02 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Maciej W. Rozycki, linux-mips
In-Reply-To: <20030108145953.B8396@linux-mips.org>
> On Wed, Jan 08, 2003 at 02:27:05PM +0100, Maciej W. Rozycki wrote:
>
> > 32-bit R4k TLB flush functions use KSEG0 as an impossible (unmapped) VPN2
> > value for invalidated TLB entries. 64-bit ones use KSEG0 as well, but
> > here KSEG0 is a valid XKSEG (mapped) value as it gets interpreted as
> > 0xc00000ff80000000 when written into cp0.EntryHi. The correct impossible
> > (unmapped) VPN2 value for the 64-bit mode is XKPHYS.
>
> That's a funny one. Historically the idea was to use KSEG0 because the
> for KSEG0 the TLB is not used for translation. That already failed for
> the Sibyte SB1 which is why we have to use different KSEG0 addresses for
> each entry there.
Amplification: some MIPS CPUs really hate having the same "virtual
address" in more than one TLB entry. Some of MIPS Technologies' own
cores are the same.
It's probably better to use legal kuseg virtual addresses (but with
the invalid bit set) for initialising TLBs. And to make them all
different...
--
Dominic Sweetman
mailto:dom@mips.com
^ permalink raw reply
* Re: [LARTC] Incomprehensive problem with tc filter & mangle...
From: Ronan LAVIEC @ 2003-01-08 18:57 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104197594226744@msgid-missing>
----- Original Message -----
From: "Stef Coene" <stef.coene@docum.org>
To: "Ronan LAVIEC" <ronan.laviec@club-internet.fr>; <lartc@mailman.ds9a.nl>
Sent: Wednesday, January 08, 2003 7:32 PM
Subject: Re: [LARTC] Incomprehensive problem with tc filter & mangle...
> > # The rules that's didn't work, and I don't now why.
> > $TC filter add dev $EXT_IFACE parent 1: protocol ip prio 15 \
> > handle 10 fw classid 1:10
> > $TC filter add dev $EXT_IFACE parent 1: protocol ip prio 20 \
> > handle 15 fw classid 1:10
> I don't think it's an issue, but you can try it without a prio parameter?
>
> Stef
>
> --
>
> stef.coene@docum.org
> "Using Linux as bandwidth manager"
> http://www.docum.org/
> #lartc @ irc.oftc.net
>
It's always the same thing...
Only the default setting seems to work.
From yesterday, I've tried with match ip src, and this also doesn't work.
($TC filter add dev $EXT_IFACE parent 1: protocol ip prio 15 u32 match ip
src $PREFERED_IP flowid 1:10)
I've tried to use mangle mark to do the same thing, and as every time always
the default setting seems to work.
I've tried another thing :
I used some rules from a script found here :
http://www.linux-france.org/prj/inetdoc/i/net/guides/Advanced-routing-Howto/
Advanced-routing-Howto.v0.9-15.html#ss15.8
So I used :
$TC filter add dev $EXT_IFACE parent 1:0 protocol ip prio 10 u32 \
match ip tos 0x10 0xff flowid 1:10
$TC filter add dev $EXT_IFACE parent 1:0 protocol ip prio 10 u32 \
match ip protocol 1 0xff flowid 1:10
$TC filter add dev $EXT_IFACE parent 1: protocol ip prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
In addition to my own rules.... And these three rules work, not mine.
I really understand anything. What's wrong with my rules ?
Ronan.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* RE: kacpidpc needs to die
From: Grover, Andrew @ 2003-01-08 18:57 UTC (permalink / raw)
To: Pavel Machek, ACPI mailing list, kernel list
> From: Pavel Machek [mailto:pavel-+ZI9xUNit7I@public.gmane.org]
> For reasons discussed before [forking from timer is not safe, anyway],
> kacpidpc needs to die. Andrew, are you going to kill it or should I do
> it?
I can kill it...let me just verify with you --
acpi_os_queue_for_execution has a two block switch statement, just use
the first block (the case that uses schedule_work) and delete the rest,
yes?
Thanks -- Regards -- Andy
^ permalink raw reply
* Re: Newbie - Where is my kernel? Can't run POM
From: Arnt Karlsen @ 2003-01-08 18:53 UTC (permalink / raw)
To: netfilter
In-Reply-To: <002301c2b73e$e0f36ca0$3f00a8c0@tharryman>
On Wed, 8 Jan 2003 11:53:38 -0600,
"Timothy Harryman" <timothy@woodlandscenics.com> wrote in message
<002301c2b73e$e0f36ca0$3f00a8c0@tharryman>:
> It certainly is not in /usr/src/linux (nautilus & terminal show that
> /usr/src is empty - yes, I am showing all hidden/system files), nor
> anywhere else I have looked.
>
> I have a default installation of RH 8.0, and through rhupdate, it has
> updated the kernel to 2.4.18-19.8.0
>
> I am trying to install patch-o-matic 20030107, and the script prompts
> me for the KERNEL_DIR.
>
> This is extremely frustrating, and any help is hugely appreciated!
>
> <>< <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
> Timothy
> timothy@woodlandscenics.com
>
>
>
..try 'rpm -ivh kernel-source-2.4.18-19.8.0.i386.rpm'. ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
^ 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.