* Re: [Alsa-devel] Re: [2.4]ALi M5451 sound hangs on init; workaround
From: Takashi Iwai @ 2002-12-11 18:34 UTC (permalink / raw)
To: Fedor Karpelevitch
Cc: Alan Cox, lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <200212110852.42778.fedor@apache.org>
At Wed, 11 Dec 2002 08:52:42 -0800,
Fedor Karpelevitch wrote:
>
> > > I have ALi M5451 souncard in my laptop (Compaq Presario 900z for
> > > those searching) and it hangs the machine with any kernel I tried
> > > (currently 2.4.20-ac1 + hirofumi patch). I traced it down to the
> > > line where it hangs - that is drivers/sound/trident.c:3379 which
> > > says: pci_write_config_byte(pci_dev, 0xB8, ~temp);
> >
> > Looking at the docs it looks like the code Matt Wu added may have
> > been meant to do
> >
> > pci_read_config_byte(pci_dev, 0x59, temp)
> > temp &= ~0x80
> > pci_write...
> >
>
> just to make sure I got it right, is the following what you suggest?
> (pseudo-patch):
>
> --------
> static int ali_close_multi_channels(void)
> {
> char temp = 0;
> struct pci_dev *pci_dev = NULL;
>
> pci_dev =pci_find_device(PCI_VENDOR_ID_AL,PCI_DEVICE_ID_AL_M1533,
> pci_dev);
> if (pci_dev == NULL)
> return -1;
> - temp = 0x80;
> + pci_read_config_byte(pci_dev, 0x59, temp);
> + temp &= ~0x80;
> - pci_write_config_byte(pci_dev, 0x59, ~temp);
> + pci_write_config_byte(pci_dev, 0x59, temp);
>
> pci_dev = pci_find_device(PCI_VENDOR_ID_AL,
> PCI_DEVICE_ID_AL_M7101, pci_dev);
> if (pci_dev == NULL)
> return -1;
>
> - temp = 0x20;
> + pci_read_config_byte(pci_dev, 0xB8, temp);
> + temp &= ~0x20
> - pci_write_config_byte(pci_dev, 0xB8, ~temp); // the line I
> + pci_write_config_byte(pci_dev, 0xB8, temp); //commented out
>
> return 0;
> }
> ---------------------
and don't forget to change similary for ali_setup_multi_channels(),
too.
> >
> > (Ditto with fixing setup_multi_cannnels)
> >
Takashi
^ permalink raw reply
* [RESEND] [OOPS & TRIVIAL PATCH 2.4.20] NULL pointer dereference in ide.c, ide_revalidate_disk()
From: Paul Clements @ 2002-12-11 18:34 UTC (permalink / raw)
To: linux-kernel; +Cc: Marcelo Tosatti
In-Reply-To: <Pine.LNX.4.10.10205291357080.28649-200000@clements.sc.steeleye.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5116 bytes --]
Problem still exists in 2.4.20. Please apply if this has not been fixed in some other way.
Thanks,
Paul
On Wed, 29 May 2002, Paul Clements wrote:
>
> Resending this patch. Looks like it did not make 2.4.19-pre9. Is there some problem in the patch
> or in my analysis, or has the problem been fixed in some other (better) way?
>
> Thanks,
> Paul
>
>
> On Wed, 8 May 2002, Paul Clements wrote:
>
> >
> > Looking back at LKML archives, I think this issue was reported by someone back in
> > November 01, and I just saw the same issue on a system a few days ago. I think I
> > have tracked down the cause of the oops. I looked to see if it had been fixed in
> > 2.4.19-pre8 and it had not, so I have attached a patch against 2.4.18. Please apply.
> >
> > The kernel oops was this:
> >
> > ----
> >
> > May 3 23:20:07 liono kernel: hda: ATAPI 32X CD-ROM drive, 256kB Cache, UDMA(33)
> > May 3 23:20:07 liono kernel: Uniform CD-ROM driver Revision: 3.12
> > May 3 23:20:07 liono kernel: hda: ide_cdrom_setup failed to register device with the cdrom driver.
> > May 3 23:20:07 liono kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000028
> > May 3 23:20:07 liono kernel: printing eip:
> > May 3 23:20:07 liono kernel: c019b54a
> > May 3 23:20:07 liono kernel: *pde = 00000000
> > May 3 23:20:07 liono kernel: Oops: 0000
> > May 3 23:20:07 liono kernel: CPU: 0
> > May 3 23:20:07 liono kernel: EIP: 0010:[ide_revalidate_disk+250/304] Not tainted
> > May 3 23:20:07 liono kernel: EIP: 0010:[<c019b54a>] Not tainted
> > May 3 23:20:07 liono kernel: EFLAGS: 00010212
> > May 3 23:20:07 liono kernel: EIP is at ide_revalidate_disk [kernel] 0xfa
> > May 3 23:20:07 liono kernel: eax: 00000000 ebx: 00000300 ecx: 00000000 edx: 00000000
> > May 3 23:20:07 liono kernel: esi: c03bdba0 edi: 00001100 ebp: 00000040 esp: c90e3ee0
> > May 3 23:20:07 liono kernel: ds: 0018 es: 0018 ss: 0018
> > May 3 23:20:07 liono kernel: Process modprobe (pid: 2028, stackpage=c90e3000)
> > May 3 23:20:07 liono kernel: Stack: 00000300 00000000 00000000 00000000 00000000 c03bde7c c019b5d2 00000300
> > May 3 23:20:07 liono kernel: cd3ce200 00000000 cd3ce348 00000002 c019dba5 d0972aa7 d09759e0 d096f000
> > May 3 23:20:07 liono kernel: 00000001 00000001 00000001 c011c685 d09758dc c903e000 000067d8 c91cd000
> > May 3 23:20:07 liono kernel: Call Trace: [revalidate_drives+82/112] revalidate_drives [kernel] 0x52
> > May 3 23:20:07 liono kernel: Call Trace: [<c019b5d2>] revalidate_drives [kernel] 0x52
> > May 3 23:20:07 liono kernel: [ide_register_module+53/64] ide_register_module [kernel] 0x35
> > May 3 23:20:07 liono kernel: [<c019dba5>] ide_register_module [kernel] 0x35
> > May 3 23:20:07 liono kernel: [aic7xxx_mod:aic7xxx_verbose+1171231/206116241] ide_cdrom_init [ide-cd] 0x187
> > May 3 23:20:07 liono kernel: [<d0972aa7>] ide_cdrom_init [ide-cd] 0x187
> > May 3 23:20:07 liono kernel: [aic7xxx_mod:aic7xxx_verbose+1183320/206104152] __insmod_ide-cd_S.data_L192 [ide-cd] 0xa0
> > May 3 23:20:07 liono kernel: [<d09759e0>] __insmod_ide-cd_S.data_L192 [ide-cd] 0xa0
> > May 3 23:20:07 liono kernel: [sys_init_module+1365/1616] sys_init_module [kernel] 0x555
> > May 3 23:20:07 liono kernel: [<c011c685>] sys_init_module [kernel] 0x555
> > May 3 23:20:07 liono kernel: [aic7xxx_mod:aic7xxx_verbose+1183060/206104412] sense_data_texts [ide-cd] 0x107c
> > May 3 23:20:07 liono kernel: [<d09758dc>] sense_data_texts [ide-cd] 0x107c
> > May 3 23:20:07 liono kernel: [aic7xxx_mod:aic7xxx_verbose+1156312/206131160] __insmod_ide-cd_O/lib/modules/2.4.9-21smp/kernel/drivers/ide/ide-cd.o_M3C472201_V132105 [ide-cd] 0x60
> > May 3 23:20:07 liono kernel: [<d096f060>] __insmod_ide-cd_O/lib/modules/2.4.9-21smp/kernel/drivers/ide/ide-cd.o_M3C472201_V132105 [ide-cd] 0x60
> > May 3 23:20:07 liono kernel: [system_call+51/56] system_call [kernel] 0x33
> > May 3 23:20:07 liono kernel: [<c010719b>] system_call [kernel] 0x33
> > May 3 23:20:07 liono kernel: [__put_unused_buffer_head+107/416] __put_unused_buffer_head [kernel] 0x6b
> > May 3 23:20:07 liono kernel: [<c014002b>] __put_unused_buffer_head [kernel] 0x6b
> > May 3 23:20:07 liono kernel:
> > May 3 23:20:07 liono kernel:
> > May 3 23:20:07 liono kernel: Code: 8b 40 28 85 c0 74 04 56 ff d0 5a 80 a6 b6 00 00 00 fb 8d 86
> >
> > ----
> >
> > So what this tells me is that (probably) a NULL pointer was dereferenced while looking for a structure
> > member with an offset of 40 (0x28) bytes. Looking through the ide_revalidate_disk function (ide.c) I find
> > that the only structure member being referenced, which also has an offset of 40 is drive->driver->revalidate
> > (via the DRIVER macro):
> >
> > if (DRIVER(drive)->revalidate)
> >
> > But there is no check for driver != NULL before it is dereferenced. In many other places throughout ide.c
> > these explicit checks are present.
> >
> > The attached patch (against 2.4.18) adds this explicit check.
> >
> > --
> > Paul Clements
> > SteelEye Technology
> > Paul.Clements@SteelEye.com
> >
>
[-- Attachment #2: patch file --]
[-- Type: TEXT/PLAIN, Size: 348 bytes --]
--- linux-2.4.18.PRISTINE/drivers/ide/ide.c Mon Apr 29 10:44:12 2002
+++ linux-2.4.18.alt/drivers/ide/ide.c Tue May 7 17:16:53 2002
@@ -1892,7 +1892,7 @@
drive->part[p].nr_sects = 0;
};
- if (DRIVER(drive)->revalidate)
+ if (DRIVER(drive) && DRIVER(drive)->revalidate)
DRIVER(drive)->revalidate(drive);
drive->busy = 0;
^ permalink raw reply
* [TRIVIAL][PATCH] fix spelling mistake
From: John Bradford @ 2002-12-11 18:50 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 90 bytes --]
I posted this an hour or so ago, but it doesn't seem to have appeared
on the list.
John.
[-- Attachment #2: ASCII English text --]
[-- Type: text/plain, Size: 618 bytes --]
--- linux-2.4.20-pre1-orig/drivers/scsi/README.ncr53c8xx 2002-12-11 17:14:48.000000000 +0000
+++ linux-2.4.20-pre1/drivers/scsi/README.ncr53c8xx 2002-12-11 17:18:24.000000000 +0000
@@ -1025,7 +1025,7 @@
then it will for sure win the next SCSI BUS arbitration.
Since, there is no way to know what devices are trying to arbitrate for the
-BUS, using this feature can be extremally unfair. So, you are not advised
+BUS, using this feature can be extremely unfair. So, you are not advised
to enable it, or at most enable this feature for the case the chip lost
the previous arbitration (boot option 'iarb:1').
^ permalink raw reply
* Re: Raid 5 on 2.5.50/2.5.51, dirty array, kernel panic
From: Steven Dake @ 2002-12-11 18:31 UTC (permalink / raw)
To: Eurijk; +Cc: linux-raid
In-Reply-To: <20021210233443.48053fe3.eurijk@zefga.net>
Eurijk
Please run the dump through ksymoops -m System.map. Without this, its
quite difficult to tell where the failure occured.
Thanks
-steve
Eurijk wrote:
>I set up an IDE raid array as such:
> /dev/md1 hda1 hdc1 hde1 hdg1 RAID 1
> /dev/md0 hda2 hdc2 hde2 hdg2 RAID 5
>
>Installed slack, set up lilo, and waited for rebuilding to finish.
>Now to simulate a failure I shut it down and physically unhooked
>(**boom hellfire fury**! :D) /dev/hda. From everything I understand,
>the system should work just fine still.
>
>Bios detects hdc is still there, and auto boots off that. Kernel loads,
>good lilo did it's job :D, but...:
>
>...
>md: created md0
>...
>md: running: <hdg2><hde2><hdc2>
>md: md0: raid array is not clean -- starting background reconstuction
>...
>raid5: device hdg2 operational as raid disk 3
>raid5: device hde2 operational as raid disk 2
>raid5: device hdc2 operational as raid disk 1
>raid5: cannot start dirty degraded array for md0
>RAID5 conf printout:
> --- rd:4 wd:3 fd:1
> disk 1, o:1, dev:hdc2
> disk 2, o:1, dev:hde2
> disk 3, o:1, dev:hdg2
>raid5: failed to run raid set md0
>md: pers->run() failed ...
>md :do_md_run() returned -22
>md: md0 still in use.
>...
>raid1: raid set md1 active with 3 out of 4 mirrors
>...
>md: ... autorun DONE.
>Unable to handle kernel NULL pointer dereference at virtual address 00000088
> printing eip:
>c0289977
>(stack/register dump is here :D)
>...
> <0>Kernel panic: Attempted to kill init!
>
>The "cannot start dirty degraded array" was added in 2.5.34 I believe. I can't
>test a pre 2.5.34 since my 20271 was added in 2.5.37. >;-) I can test it using
>good ol' hda/hdb/hdc/hdd if it would be of some help.
>
>Let me know if I'm off my rocker!
>
>Thanks
>
>-eurijk!
>-
>To unsubscribe from this list: send the line "unsubscribe linux-raid" 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: [2.4]ALi M5451 sound hangs on init; workaround
From: Fedor Karpelevitch @ 2002-12-11 18:36 UTC (permalink / raw)
To: Fedor Karpelevitch, Alan Cox
Cc: lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <200212110852.42778.fedor@apache.org>
> > > I have ALi M5451 souncard in my laptop (Compaq Presario 900z
> > > for those searching) and it hangs the machine with any kernel I
> > > tried (currently 2.4.20-ac1 + hirofumi patch). I traced it down
> > > to the line where it hangs - that is
> > > drivers/sound/trident.c:3379 which says:
> > > pci_write_config_byte(pci_dev, 0xB8, ~temp);
> >
> > Looking at the docs it looks like the code Matt Wu added may have
> > been meant to do
> >
> > pci_read_config_byte(pci_dev, 0x59, temp)
> > temp &= ~0x80
> > pci_write...
>
> ---------------------
> I'll try it and will tell you what the result is. Anyway, what are
> those commands doing, i.e. what am I loosing when I comment it out?
> Is there some specific functionality I should test to see the
> result of these changes?
>
> > and similarly for the other port
> >
> > (Ditto with fixing setup_multi_cannnels)
> >
> > Does it work sanely with those fixd ?
here is what I i got it work with:
--------
static int ali_close_multi_channels(void)
{
char temp = 0;
struct pci_dev *pci_dev = NULL;
pci_dev
=pci_find_device(PCI_VENDOR_ID_AL,PCI_DEVICE_ID_AL_M1533,
pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x80;
+ pci_read_config_byte(pci_dev, 0x59, &temp);
+ temp &= ~0x80;
- pci_write_config_byte(pci_dev, 0x59, ~temp);
+ pci_write_config_byte(pci_dev, 0x59, temp);
pci_dev = pci_find_device(PCI_VENDOR_ID_AL,
PCI_DEVICE_ID_AL_M7101, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x20;
+ pci_read_config_byte(pci_dev, 0xB8, &temp);
+ temp &= ~0x20
- pci_write_config_byte(pci_dev, 0xB8, ~temp); // the line I
+ pci_write_config_byte(pci_dev, 0xB8, temp); //commented out
return 0;
}
---------------------
almost as I posted before, just passing pointers to the read method.
It works, but the question as to what is this supposed to affect
remains...
should similar changes be made elsewhere in this driver? I better not
change blindly what I do not quite understand...
Fedor
^ permalink raw reply
* RAM and swap partition
From: Rolf Edlund @ 2002-12-11 18:32 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <3DF3BD16.AEDD6560@gelm.net>
Originally to: Chuck Gelm
CG> IMHO, it depends. ;-)
Looks like it. I have to test and see.. :)
... To quote or not to quote, that is the question.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: Re: [2.4]ALi M5451 sound hangs on init; workaround
From: Takashi Iwai @ 2002-12-11 18:34 UTC (permalink / raw)
To: Fedor Karpelevitch
Cc: Alan Cox, lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <200212110852.42778.fedor@apache.org>
At Wed, 11 Dec 2002 08:52:42 -0800,
Fedor Karpelevitch wrote:
>
> > > I have ALi M5451 souncard in my laptop (Compaq Presario 900z for
> > > those searching) and it hangs the machine with any kernel I tried
> > > (currently 2.4.20-ac1 + hirofumi patch). I traced it down to the
> > > line where it hangs - that is drivers/sound/trident.c:3379 which
> > > says: pci_write_config_byte(pci_dev, 0xB8, ~temp);
> >
> > Looking at the docs it looks like the code Matt Wu added may have
> > been meant to do
> >
> > pci_read_config_byte(pci_dev, 0x59, temp)
> > temp &= ~0x80
> > pci_write...
> >
>
> just to make sure I got it right, is the following what you suggest?
> (pseudo-patch):
>
> --------
> static int ali_close_multi_channels(void)
> {
> char temp = 0;
> struct pci_dev *pci_dev = NULL;
>
> pci_dev =pci_find_device(PCI_VENDOR_ID_AL,PCI_DEVICE_ID_AL_M1533,
> pci_dev);
> if (pci_dev == NULL)
> return -1;
> - temp = 0x80;
> + pci_read_config_byte(pci_dev, 0x59, temp);
> + temp &= ~0x80;
> - pci_write_config_byte(pci_dev, 0x59, ~temp);
> + pci_write_config_byte(pci_dev, 0x59, temp);
>
> pci_dev = pci_find_device(PCI_VENDOR_ID_AL,
> PCI_DEVICE_ID_AL_M7101, pci_dev);
> if (pci_dev == NULL)
> return -1;
>
> - temp = 0x20;
> + pci_read_config_byte(pci_dev, 0xB8, temp);
> + temp &= ~0x20
> - pci_write_config_byte(pci_dev, 0xB8, ~temp); // the line I
> + pci_write_config_byte(pci_dev, 0xB8, temp); //commented out
>
> return 0;
> }
> ---------------------
and don't forget to change similary for ali_setup_multi_channels(),
too.
> >
> > (Ditto with fixing setup_multi_cannnels)
> >
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: [2.4]ALi M5451 sound hangs on init; workaround
From: Fedor Karpelevitch @ 2002-12-11 18:36 UTC (permalink / raw)
To: Fedor Karpelevitch, Alan Cox
Cc: lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <200212110852.42778.fedor@apache.org>
> > > I have ALi M5451 souncard in my laptop (Compaq Presario 900z
> > > for those searching) and it hangs the machine with any kernel I
> > > tried (currently 2.4.20-ac1 + hirofumi patch). I traced it down
> > > to the line where it hangs - that is
> > > drivers/sound/trident.c:3379 which says:
> > > pci_write_config_byte(pci_dev, 0xB8, ~temp);
> >
> > Looking at the docs it looks like the code Matt Wu added may have
> > been meant to do
> >
> > pci_read_config_byte(pci_dev, 0x59, temp)
> > temp &= ~0x80
> > pci_write...
>
> ---------------------
> I'll try it and will tell you what the result is. Anyway, what are
> those commands doing, i.e. what am I loosing when I comment it out?
> Is there some specific functionality I should test to see the
> result of these changes?
>
> > and similarly for the other port
> >
> > (Ditto with fixing setup_multi_cannnels)
> >
> > Does it work sanely with those fixd ?
here is what I i got it work with:
--------
static int ali_close_multi_channels(void)
{
char temp = 0;
struct pci_dev *pci_dev = NULL;
pci_dev
=pci_find_device(PCI_VENDOR_ID_AL,PCI_DEVICE_ID_AL_M1533,
pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x80;
+ pci_read_config_byte(pci_dev, 0x59, &temp);
+ temp &= ~0x80;
- pci_write_config_byte(pci_dev, 0x59, ~temp);
+ pci_write_config_byte(pci_dev, 0x59, temp);
pci_dev = pci_find_device(PCI_VENDOR_ID_AL,
PCI_DEVICE_ID_AL_M7101, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x20;
+ pci_read_config_byte(pci_dev, 0xB8, &temp);
+ temp &= ~0x20
- pci_write_config_byte(pci_dev, 0xB8, ~temp); // the line I
+ pci_write_config_byte(pci_dev, 0xB8, temp); //commented out
return 0;
}
---------------------
almost as I posted before, just passing pointers to the read method.
It works, but the question as to what is this supposed to affect
remains...
should similar changes be made elsewhere in this driver? I better not
change blindly what I do not quite understand...
Fedor
-------------------------------------------------------
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: RAID5 chunksize?
From: Bill Davidsen @ 2002-12-11 18:47 UTC (permalink / raw)
To: Robert L. Harris; +Cc: Linux-Kernel
In-Reply-To: <20021210152330.GP32203@rdlg.net>
On Tue, 10 Dec 2002, Robert L. Harris wrote:
>
>
> Ok, say I'm building a 4 disk raid5 array. Performance is going to be
> critical as this system is going to be very IO intensive. We had to go
> RAID5 though due to filesystem requirements.
>
> According to the manufacturer the disks have:
>
> 8Meg DataBuffer
> 10K RPM Rotational speed
> SCSI Ultra 160
>
> (Drive is:
> http://www.fel.fujitsu.com/home/product.asp?L=en&PID=248&INFO=fsp)
>
> What is the ideal Chunksize?
That depends on your definition of ideal, unfortunately.
> Any other thoughts on how to lay down the disks/filesystem on this
> bugger?
Yes, I got a chance to spend a LOT of time tuning RAID, and got to see
what various settings actually did.
You have to decide if you want to have maximum transfer rate or minimum
seeks on the drive. Some of the changes impact one at the expense of the
other.
If you want to reduce seeks, make the stripe size larger than most of the
i/o requests, so you access at most two drives. This will reduce your
seeks, a too-small stripe can result in activity to most of the drives for
most i/o operations. Lots of seeks, and bad performance if transfers are
fairly small, a request can't complete until the slowest seek+transfer is
complete.
If the typical write is large, defined as transfer time significantly more
than seek time, you can improve transfer rate by spreading the transfer
over multiple drives, as long as you don't overload your bus. This last
gets important, a few controllers with multiple sets of LVD-160 or faster
drives can start to stress the PCI bus, and enough DMA (or similar bus
master i/o) can actually hit the memory hard enough to measure in the CPU
access time. Clearly these limits are not typical, you idea of high rate
might be idle on some NUMA or cluster. Since this increases the seek rate
on individual drives, you can hurt more than you help with certain loads.
Finally, if you have a very high read rate and much lower write rate, you
can help with RAID-1, so that data on one (busy) drive can be pulled from
a mirror. You *can* have more than two mirrored copies, if your load
justifies it.
Hope some of this helps you answer your own question.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-11 18:50 UTC (permalink / raw)
To: Terje Eggestad; +Cc: linux-kernel, Dave Jones
In-Reply-To: <1039610907.25187.190.camel@pc-16.office.scali.no>
Terje Eggestad wrote:
> It get even worse with Hammer. When you run hammer in compatibility mode
> (32 bit app on a 64 bit OS) the sysenter is an illegal instruction.
>
> Since Intel don't implement syscall, there is no portable sys*
> instruction for 32 bit apps. You could argue that libc hides it for you
> and you just need libc to test the host at startup (do I get a sigill if
> I try to do getpid() with sysenter? syscall? if so we uses int80 for
> syscalls). But not all programs are linked dyn.
Linus talked about this once, and it was agreed that the only sane way
to do this properly was via vsyscalls... have a page mapped somewhere in
high (kernel-area) memory, say at 0xfffff000, but readable by normal
processes. A system call can be invoked via call 0xfffff000, and the
*kernel* enters whatever code is appropriate to enter itself.
> Too bad really, I tried the sysenter patch once, and the gain (on PIII
> and athlon) was significant.
>
> Fortunately the 64bit libc for hammer uses syscall.
>
Yes.
>
> PS: rdtsc on P4 is also painfully slow!!!
>
Now that's just braindead...
-hpa
^ permalink raw reply
* Bug Report 2.4.20: Interrupt sharing bogus
From: Stephan von Krawczynski @ 2002-12-11 18:55 UTC (permalink / raw)
To: linux-kernel; +Cc: Marcelo Tosatti
Hello all,
It took me several days to find out this pretty simple sounding problem:
I have a stock 2.4.20 on a PIII-box with SIS chipset (lspci below), adaptec
U160-type controller and tulip-based 4-port ethernet card.
_If_ I use an ethernet port with same irq like adaptec controller, the system
goes instable and both components go crazy. Ethernet connections break down,
reading and writing from/to hd gives errors. The problem is reproducable with
another hardware with same components and even with a different (sundance)
4-port ethernet card. For tests I simply copy a lot of files via NFS to the
local hd. It always freezes the machine, not always ad-hoc, but within short.
I checked with 2.4.19 - same problem.
I can test patches on this, no production machine involved. Any hints appreciated.
lspci -vv:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 30)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 32
Region 0: Memory at d8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [c0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=x4
00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8a [Master SecP PriP])
Subsystem: Silicon Integrated Systems [SiS] SiS5513 EIDE Controller (A,B step)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at <ignored> [disabled]
Region 1: I/O ports at <ignored> [disabled]
Region 2: I/O ports at <ignored> [disabled]
Region 3: I/O ports at <ignored> [disabled]
Region 4: I/O ports at 4000 [disabled] [size=16]
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:01.1 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet (rev 84)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (13000ns min, 2750ns max)
Interrupt: pin C routed to IRQ 14
Region 0: I/O ports at c000 [size=256]
Region 1: Memory at e1102000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=160mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
00:02.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00009000-00009fff
Memory behind bridge: e1000000-e10fffff
Prefetchable memory behind bridge: d0000000-d7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
00:12.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 0000a000-0000afff
Memory behind bridge: dd000000-deffffff
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=220mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
00:13.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Bus: primary=00, secondary=03, subordinate=03, sec-latency=32
I/O behind bridge: 0000b000-0000bfff
Memory behind bridge: df000000-e0ffffff
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=220mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS630 GUI Accelerator+3D (rev 21) (prog-if 00 [VGA])
Subsystem: Silicon Integrated Systems [SiS] SiS630 GUI Accelerator+3D
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
BIST result: 00
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Region 1: Memory at e1000000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at 9000 [size=128]
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] AGP version 2.0
Status: RQ=15 SBA+ 64bit- FW- Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
02:04.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
Subsystem: Adaptec 29160 Ultra160 SCSI Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (10000ns min, 6250ns max), cache line size 08
Interrupt: pin A routed to IRQ 15
BIST result: 00
Region 0: I/O ports at a000 [disabled] [size=256]
Region 1: Memory at de011000 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
02:06.0 Network controller: Siemens Nixdorf AG DSCC4 WAN adapter (rev 21)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (750ns min, 2500ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at de010000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at de000000 (32-bit, non-prefetchable) [size=64K]
02:07.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!PCI v2.0 ISDN (rev 01)
Subsystem: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!PCI v2.0 ISDN
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 14
Region 0: Memory at de012000 (32-bit, non-prefetchable) [size=32]
Region 1: I/O ports at a400 [size=32]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
03:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: D-Link System Inc: Unknown device 1132
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (5000ns min, 10000ns max), cache line size 08
Interrupt: pin A routed to IRQ 14
Region 0: I/O ports at b000 [size=128]
Region 1: Memory at e0000000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=256K]
03:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: D-Link System Inc: Unknown device 1132
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (5000ns min, 10000ns max), cache line size 08
Interrupt: pin A routed to IRQ 15
Region 0: I/O ports at b400 [size=128]
Region 1: Memory at e0001000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=256K]
03:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: D-Link System Inc: Unknown device 1132
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (5000ns min, 10000ns max), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at b800 [size=128]
Region 1: Memory at e0002000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=256K]
03:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: D-Link System Inc: Unknown device 1132
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (5000ns min, 10000ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at bc00 [size=128]
Region 1: Memory at e0003000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=256K]
--
Regards,
Stephan
^ permalink raw reply
* Re: fetchmail and smtp problem
From: Haines Brown @ 2002-12-11 18:51 UTC (permalink / raw)
To: ray; +Cc: linux-newbie
In-Reply-To: <5.1.0.14.1.20021210171852.020d3150@celine>
I ran fetchmail -V to get the version and other info, and there's
little difference from what I've got with my current (RH7.3)
system. The only difference is that on my current (RH7.3) system, old
messages are flushed before retrieval, while on new system (RH8.0)
--flush off.
================================================================
Here is a bounced message. It was rejected by my own mailserver:
returned message:
Date: Tue, 10 Dec 2002 17:42:16 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON@hartford-hwp.com>
To: brownh@hartford-hwp.com
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)
----- The following addresses had permanent fatal errors -----
127.0.0.1
(reason: 550 5.1.1 <127.0.0.1@hartford-hwp.com>... User unknown)
(expanded from: 127.0.0.1)
----- Transcript of session follows -----
... while talking to hartford-hwp.com.:
>>> DATA
<<< 550 5.1.1 <127.0.0.1@hartford-hwp.com>... User unknown
550 5.1.1 127.0.0.1... User unknown
--gBAMgENo000872.1039560136/hartford-hwp.com
Content-Type: message/delivery-status
Reporting-MTA: dns; hartford-hwp.com
Arrival-Date: Tue, 10 Dec 2002 13:58:47 -0500
Final-Recipient: RFC822; 127.0.0.1@hartford-hwp.com
Action: failed
Status: 5.1.1
Remote-MTA: DNS; hartford-hwp.com
Diagnostic-Code: SMTP; 550 5.1.1 <127.0.0.1@hartford-hwp.com>... User unknown
Last-Attempt-Date: Tue, 10 Dec 2002 17:42:16 -0500
--gBAMgENo000872.1039560136/hartford-hwp.com
Content-Type: message/rfc822
Return-Path: <brownh>
Received: (from brownh@localhost)
by hartford-hwp.com (8.12.5/8.12.5/Submit) id gBAIwl3h003184;
Tue, 10 Dec 2002 13:58:47 -0500
Date: Tue, 10 Dec 2002 13:58:47 -0500
Message-Id: <200212101858.gBAIwl3h003184@hartford-hwp.com>
From: Haines Brown <brownh@hartford-hwp.com>
To: 127.0.0.1
Subject: test from lo 10 dec 13:58
Reply-to: brownh@hartford-hwp.com
...
---
Something's messed up here with my identity. 127.0.0.1 is not a UID on
my domain. I don't recall what "test from lo" means unless for some
reason I mailed the message to the lo IP address, which perhaps
explains it, but does not hint at what happened to messages mailed to
myself.
=========================================================
This is my ~/.fetchmailrc:
set postmaster "postmaster"
poll pop.registeredsite.com
proto POP3
user "brownh@hartford-hwp.com"
password "<password>"
limit 100000
flush
I also tried
poll pop.registeredsite.com
proto POP3
user brownh@hartford-hwp.com
password <password>
but no difference. Mail files very slow to download, but then groups
of several come in a burst in the midst of slow ones. That's the usual
problem.
==========================================================
I did a fetchmail --configdump dump and find that the only diff
with the dump from my current (RH7i.3) machine is:
9c9
< "idfile":"/home/brownh/.fetchids",
---
> "idfile":"/root/.fetchids",
46c46
< 'localnames':["brownh"],
---
> 'localnames':["root"],
child process exited abnormally
I assume (hope!) this diff only because I inadvertantly ran it as
root. Obviously I'll need to verify that presumption.
==========================================================
I was going to regenerate a ~/.fetchmailrc file automatically with
fetchmailconf, but find that utility is not included in RH8.0. The man
fetchmail presumes it is present. The fetchmail web page says it comes
packaged with fetchmail. Why it is missing, I don't know. In light of
my damaged rp-pppoe, I worry that the fetchmail installation might be
flawed. But rpm -V didn't report anything.
I have a much newer fetchmail rpm for a i686 machine that I'm tempted
to install, but my use of fetchmail takes advantage of a bug in the
program (flushing messages over a certain size before downloading
them, which is not supposed to be possible), and I hestitate for that
reason to change things. But if fetchmailconf is supposed to work
under RH8.0, I may have to reinstall fetchmail.
Haines Brown
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Destroying processes
From: Justin Hibbits @ 2002-12-11 19:01 UTC (permalink / raw)
To: linux-kernel
Hey 00ber-geeks,
I'm not subscribed (yet....still too lazy to subscribe ;P ), but I have a
question and/or suggestion.
Is there a system call that would destroy a process? Sometimes I end up with
zombie processes, other times I end up with a process attaching to a device
driver, and hanging, so I want to be able to completely destroy the
process...image, file handle, driver hooks, everything. If there isn't one,
and noone wants to do it, I'll gladly do it (may take a few weeks tho). I just
don't wanna do what someone else has already done.
Thanks,
Justin Hibbits
--
Registered Linux user 260206
"One World, One Web, One Program"
- Microsoft Promo Ad
"Ein Volk, Ein Reich, Ein Fuhrer"
- Adolf Hitler
I'm not paranoid. They really *are* out to get me!
^ permalink raw reply
* RE: 2.5 Changes doc update.
From: Alan Cox @ 2002-12-11 19:37 UTC (permalink / raw)
To: Holzrichter, Bruce; +Cc: 'Dave Jones', Linux Kernel Mailing List
In-Reply-To: <61DB42B180EAB34E9D28346C11535A7801130352@nocmail101.ma.tmpw.net>
On Wed, 2002-12-11 at 17:38, Holzrichter, Bruce wrote:
> FWIW to you, though I know this is mostly x86 centric, there are Endian
> issues with current 2.5 IDE, and Big Endian machines such as sparc64 won't
> work right now with IDE.
I think sparc64 is currently the only broken platform like that. I've
got some bits from this nutter called Dave I'm merging bit by bit.
2.4.20-ac2 has the length fixes done.
Alan
^ permalink raw reply
* slram and buffer cache
From: Tobias Otto-Adamczak @ 2002-12-11 19:23 UTC (permalink / raw)
To: linux-mtd; +Cc: Jochen Schaeuble
Hi,
I have a custom board with 32MB SDRAM, 16MB Flash and 512K SRAM here. I
use the slram driver to access the SRAM (which isn't used otherwise by
the kernel). I created an 512K ext2 fs image and copied it to the SRAM
using an mtd char dev. I was able to mount this SRAM area as a mtd block
device (using mtdblock_ro) and read/write files to the ext2 fs.
My problem is the buffer cache for the block devices. I do not want
write operations to the SRAM being delayed. What can I do to avoid that
? I searched for some hours today but to no avail.
[maybe OT for this list]
How is this problem solved for "normal" ram disks ?
Regards
Tobias
^ permalink raw reply
* [U-Boot-Users] uncompressing two gziped images
From: Rod Boyce @ 2002-12-11 18:53 UTC (permalink / raw)
To: u-boot
All,
We are using U-Boot to start a new PPC platform. One of the things we need
to do is to load hardware debug software and start it. U-Boot does this
very well but we also need to load a data pack. This data pack is big for
our flash but we can compress it.
My question is how can I uncompress two stand alone images before starting
one of them (the first one)?
Before I start changing the code to do this for us I though I'd ask incase
there is a way I have not been able to figure out yet. I have tried using
mkimage and setting one to a Linux kernel image and the other one to a RAM
disk but the RAM disk is not decompressed before being relocated.
Regards,
Rod Boyce
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Bill Davidsen @ 2002-12-11 18:51 UTC (permalink / raw)
To: Alan Cox; +Cc: Daniel Egger, Dave Jones, Joseph, Linux Kernel Mailing List
In-Reply-To: <1039539080.14302.29.camel@irongate.swansea.linux.org.uk>
On 10 Dec 2002, Alan Cox wrote:
>
> > Interesting. I have no clue about which C3 you're talking about here but
> > a VIA Ezra has all 686 instructions including cmov and thus optimising
> > for PPro works best for me.
>
> Well if you optimise for ppro it won't actually always work. Also the
> scheduling seems to be best with 486. Remember the C3 is a single issue
> risc processor.
Is this the CPU in the $200 "Lindows" PC Wal-Mart is selling? I was
thinking of one for a low volume router, and it looks as if there are two
VIA chips called C3 (or advertizers have hacked the specs).
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: Bug Report 2.4.20: Interrupt sharing bogus
From: Alan Cox @ 2002-12-11 19:45 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Linux Kernel Mailing List, Marcelo Tosatti
In-Reply-To: <20021211195501.7f6dff35.skraw@ithnet.com>
On Wed, 2002-12-11 at 18:55, Stephan von Krawczynski wrote:
> 4-port ethernet card. For tests I simply copy a lot of files via NFS to the
> local hd. It always freezes the machine, not always ad-hoc, but within short.
> I checked with 2.4.19 - same problem.
> I can test patches on this, no production machine involved. Any hints appreciated.
Not all systems get on with the 4 ports and bridge stuff. Also make sure
you have APIC disabled as the SiS io apic has some fun features 2.4
doesnt yet have workarounds for
^ permalink raw reply
* RE: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
From: Margit Schubert-While @ 2002-12-11 19:09 UTC (permalink / raw)
To: linux-kernel
>Keith Whitwell wrote:
>diff -u -r1.9 drm_agpsupport.h
>--- drm_agpsupport.h 22 Aug 2002 19:35:31 -0000 1.9
>+++ drm_agpsupport.h 11 Dec 2002 13:29:18 -0000
>@@ -260,60 +260,6 @@
> return NULL;
> }
> head->memory = NULL;
>- switch (head->agp_info.chipset) {
>- case INTEL_GENERIC: head->chipset = "Intel"; break;
Think you missed something at line 258.
Margit
^ permalink raw reply
* Re: [parisc-linux] smp crash in version 2.4.20-pa13
From: Randolph Chung @ 2002-12-11 19:06 UTC (permalink / raw)
To: FARINATI,LEANDRO (HP-Brazil,ex1); +Cc: Parisc-Linux List (E-mail)
In-Reply-To: <9A0482A7BD2506488AD9417C93F3714FB865E1@xsp01.brazil.hp.com>
> I'm trying to run Linux (compiled with smp, kernel version 2.4.20-pa13) on a
> single-processed C3600 workstation and I receive the folowing error message
> at boot time:
Again, you need to follow the info at
http://www.parisc-linux.org/faq/kernelbug-howto.html
when reporting things like this.
Especially the part in *bold*.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Dave Jones @ 2002-12-11 19:14 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Alan Cox, Daniel Egger, Joseph, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.3.96.1021211134909.19397B-100000@gatekeeper.tmr.com>
On Wed, Dec 11, 2002 at 01:51:13PM -0500, Bill Davidsen wrote:
> Is this the CPU in the $200 "Lindows" PC Wal-Mart is selling?
Yes. Looks like it judging from
http://www.walmart.com/catalog/product_listing.gsp?path=0%3A3944%3A3951%3A41937%3A86796%3A96356&dept=3944&cat=96356&sb=61&bti=0
> I was thinking of one for a low volume router,
Seems to do the job nicely for me.
> and it looks as if there are two
> VIA chips called C3 (or advertizers have hacked the specs).
http://www.viaarena.com/?PageID=15
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: fetchmail and smtp problem
From: Ray Olszewski @ 2002-12-11 19:09 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <200212111851.gBBIpGB03369@hartford-hwp.com>
Haines -- It is hard to diagnose anything from this bounce, without
information about what the original message looked like. A ways down in the
bounce report is this information:
>Date: Tue, 10 Dec 2002 13:58:47 -0500
>Message-Id: <200212101858.gBAIwl3h003184@hartford-hwp.com>
>From: Haines Brown <brownh@hartford-hwp.com>
>To: 127.0.0.1
>Subject: test from lo 10 dec 13:58
>Reply-to: brownh@hartford-hwp.com
The first question you need to answer is -- how did 127.0.0.1 get into the
"To:" header? Was it an addressing error on your part, or did something
rewrite it to that value? I'd suggest you check the outbox of whatever
program you used to send the message. If the "To: 127.0.0.1" line appears
in your original, then it was just a typo and of no significance to your
troubleshooting (that is, the reject is correct). If the original has a
different To: line, then post a followup with the details -- what MUA,
which system (hard disk) you were using, and what the original To: line said.
If it aids your memory, this message has a timestamp just 10 minutes before
the one on the telnet test you did (and reported on) yesterday.
At 01:51 PM 12/11/02 -0500, Haines Brown wrote:
>I ran fetchmail -V to get the version and other info, and there's
>little difference from what I've got with my current (RH7.3)
>system. The only difference is that on my current (RH7.3) system, old
>messages are flushed before retrieval, while on new system (RH8.0)
>--flush off.
>
>================================================================
>
>Here is a bounced message. It was rejected by my own mailserver:
[details deleted]
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: "bio too big" error
From: Greg KH @ 2002-12-11 19:16 UTC (permalink / raw)
To: Wil Reichert; +Cc: linux-kernel
In-Reply-To: <1039614035.478.48.camel@darwin>
On Wed, Dec 11, 2002 at 08:40:35AM -0500, Wil Reichert wrote:
> > Did you try the dm patches that were just posted to lkml today?
>
> Just subscribed today, missed 'em. You're refering to
>
> http://people.sistina.com/~thornber/patches/2.5-stable/2.5.50/2.5.50-dm-2.tar.bz2 ?
Nope, try the ones at:
http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/
thanks,
greg k-h
^ permalink raw reply
* [PATCH] updated preemptive-kernel patches for 2.4
From: Robert Love @ 2002-12-11 19:18 UTC (permalink / raw)
To: linux-kernel; +Cc: kpreempt-tech
Patches for 2.4.20, 2.4.20-ac1, 2.4.21-pre1 and older kernels are
available at:
http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/
This is just a resync with the new kernels; the core of the patch is
unchanged.
Enjoy,
Robert Love
^ permalink raw reply
* [PATCH] intermezzo fixes for 2.5.50
From: Peter Braam @ 2002-12-11 19:21 UTC (permalink / raw)
To: torvalds, linux-kernel, intermezzo-devel, rddunlap
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]
Hello,
Please find attached relatively straightforward fixes for intermezzo
problems in 2.5.50. I think all of them related to:
- two missing headers
- use of timespec instead of time_t.
- Peter -
[-- Attachment #2: intermezzo.patch --]
[-- Type: text/plain, Size: 36082 bytes --]
patches to be applied to specific kernels to get intermezzo working
fs/intermezzo/dir.c | 6
fs/intermezzo/file.c | 2
fs/intermezzo/journal.c | 12 +
fs/intermezzo/kml_reint.c | 42 +++--
fs/intermezzo/kml_unpack.c | 12 +
fs/intermezzo/presto.c | 6
fs/intermezzo/replicator.c | 3
fs/intermezzo/vfs.c | 4
include/linux/fsfilter.h | 134 ++++++++++++++++++
include/linux/intermezzo_fs.h | 2
include/linux/intermezzo_idl.h | 304 +++++++++++++++++++++++++++++++++++++++++
include/linux/intermezzo_lib.h | 168 ++++++++++++++++++++++
12 files changed, 663 insertions(+), 32 deletions(-)
--- linux-2.5.50/fs/intermezzo/dir.c~intermezzo Tue Dec 10 20:53:33 2002
+++ linux-2.5.50-root/fs/intermezzo/dir.c Tue Dec 10 20:53:33 2002
@@ -342,7 +342,7 @@ int presto_setattr(struct dentry *de, st
int error;
struct presto_cache *cache;
struct presto_file_set *fset;
- struct lento_vfs_context info = { 0, 0, 0 };
+ struct lento_vfs_context info = { 0, {0}, 0 };
ENTRY;
@@ -358,8 +358,8 @@ int presto_setattr(struct dentry *de, st
CDEBUG(D_INODE, "valid %#x, mode %#o, uid %u, gid %u, size %Lu, "
"atime %lu mtime %lu ctime %lu flags %d\n",
iattr->ia_valid, iattr->ia_mode, iattr->ia_uid, iattr->ia_gid,
- iattr->ia_size, iattr->ia_atime, iattr->ia_mtime,
- iattr->ia_ctime, iattr->ia_attr_flags);
+ iattr->ia_size, iattr->ia_atime.tv_sec, iattr->ia_mtime.tv_sec,
+ iattr->ia_ctime.tv_sec, iattr->ia_attr_flags);
if ( presto_get_permit(de->d_inode) < 0 ) {
EXIT;
--- linux-2.5.50/fs/intermezzo/file.c~intermezzo Tue Dec 10 20:53:33 2002
+++ linux-2.5.50-root/fs/intermezzo/file.c Tue Dec 10 20:53:33 2002
@@ -61,7 +61,7 @@ extern int presto_permission(struct inod
static int presto_open_upcall(int minor, struct dentry *de)
{
- int rc;
+ int rc = 0;
char *path, *buffer;
struct presto_file_set *fset;
int pathlen;
--- linux-2.5.50/fs/intermezzo/journal.c~intermezzo Tue Dec 10 20:53:33 2002
+++ linux-2.5.50-root/fs/intermezzo/journal.c Tue Dec 10 20:59:09 2002
@@ -363,8 +363,10 @@ static inline char *log_dentry_version(c
presto_getversion(&version, dentry->d_inode);
- version.pv_mtime = HTON__u64(version.pv_mtime);
- version.pv_ctime = HTON__u64(version.pv_ctime);
+ version.pv_mtime_sec = HTON__u32(version.pv_mtime_sec);
+ version.pv_ctime_sec = HTON__u32(version.pv_ctime_sec);
+ version.pv_mtime_nsec = HTON__u32(version.pv_mtime_nsec);
+ version.pv_ctime_nsec = HTON__u32(version.pv_ctime_nsec);
version.pv_size = HTON__u64(version.pv_size);
return logit(buf, &version, sizeof(version));
@@ -376,8 +378,10 @@ static inline char *log_version(char *bu
memcpy(&version, pv, sizeof(version));
- version.pv_mtime = HTON__u64(version.pv_mtime);
- version.pv_ctime = HTON__u64(version.pv_ctime);
+ version.pv_mtime_sec = HTON__u32(version.pv_mtime_sec);
+ version.pv_mtime_nsec = HTON__u32(version.pv_mtime_nsec);
+ version.pv_ctime_sec = HTON__u32(version.pv_ctime_sec);
+ version.pv_ctime_nsec = HTON__u32(version.pv_ctime_nsec);
version.pv_size = HTON__u64(version.pv_size);
return logit(buf, &version, sizeof(version));
--- linux-2.5.50/fs/intermezzo/kml_reint.c~intermezzo Tue Dec 10 20:53:33 2002
+++ linux-2.5.50-root/fs/intermezzo/kml_reint.c Tue Dec 10 21:08:12 2002
@@ -100,7 +100,8 @@ static inline int version_equal(struct p
return 0;
}
- if (inode->i_mtime == a->pv_mtime &&
+ if (inode->i_mtime.tv_sec == a->pv_mtime_sec &&
+ inode->i_mtime.tv_nsec == a->pv_mtime_nsec &&
(S_ISDIR(inode->i_mode) || inode->i_size == a->pv_size))
return 1;
@@ -126,8 +127,10 @@ static int reint_close(struct kml_rec *r
struct iattr iattr;
iattr.ia_valid = ATTR_CTIME | ATTR_MTIME | ATTR_SIZE;
- iattr.ia_mtime = (time_t)rec->new_objectv->pv_mtime;
- iattr.ia_ctime = (time_t)rec->new_objectv->pv_ctime;
+ iattr.ia_mtime.tv_sec = (time_t)rec->new_objectv->pv_mtime_sec;
+ iattr.ia_mtime.tv_nsec = (time_t)rec->new_objectv->pv_mtime_nsec;
+ iattr.ia_ctime.tv_sec = (time_t)rec->new_objectv->pv_ctime_sec;
+ iattr.ia_ctime.tv_nsec = (time_t)rec->new_objectv->pv_ctime_nsec;
iattr.ia_size = (time_t)rec->new_objectv->pv_size;
/* no kml record, but update last rcvd */
@@ -144,7 +147,8 @@ static int reint_close(struct kml_rec *r
} else {
int minor = presto_f2m(fset);
- info.updated_time = rec->new_objectv->pv_mtime;
+ info.updated_time.tv_sec = rec->new_objectv->pv_mtime_sec;
+ info.updated_time.tv_nsec = rec->new_objectv->pv_mtime_nsec;
memcpy(&info.remote_version, rec->old_objectv,
sizeof(*rec->old_objectv));
info.remote_ino = rec->ino;
@@ -180,7 +184,8 @@ static int reint_create(struct kml_rec *
int error; ENTRY;
CDEBUG (D_KML, "=====REINT_CREATE::%s\n", rec->path);
- info->updated_time = rec->new_objectv->pv_ctime;
+ info->updated_time.tv_sec = rec->new_objectv->pv_ctime_sec;
+ info->updated_time.tv_nsec = rec->new_objectv->pv_ctime_nsec;
kmlreint_pre_secure(rec, dir, &saved_ctxt);
error = lento_create(rec->path, rec->mode, info);
pop_ctxt(&saved_ctxt);
@@ -198,7 +203,8 @@ static int reint_link(struct kml_rec *re
ENTRY;
CDEBUG (D_KML, "=====REINT_LINK::%s -> %s\n", rec->path, rec->target);
- info->updated_time = rec->new_objectv->pv_mtime;
+ info->updated_time.tv_sec = rec->new_objectv->pv_mtime_sec;
+ info->updated_time.tv_nsec = rec->new_objectv->pv_mtime_nsec;
kmlreint_pre_secure(rec, dir, &saved_ctxt);
error = lento_link(rec->path, rec->target, info);
pop_ctxt(&saved_ctxt);
@@ -216,7 +222,8 @@ static int reint_mkdir(struct kml_rec *r
ENTRY;
CDEBUG (D_KML, "=====REINT_MKDIR::%s\n", rec->path);
- info->updated_time = rec->new_objectv->pv_ctime;
+ info->updated_time.tv_sec = rec->new_objectv->pv_ctime_sec;
+ info->updated_time.tv_nsec = rec->new_objectv->pv_ctime_nsec;
kmlreint_pre_secure(rec, dir, &saved_ctxt);
error = lento_mkdir(rec->path, rec->mode, info);
pop_ctxt(&saved_ctxt);
@@ -234,7 +241,8 @@ static int reint_mknod(struct kml_rec *r
ENTRY;
CDEBUG (D_KML, "=====REINT_MKNOD::%s\n", rec->path);
- info->updated_time = rec->new_objectv->pv_ctime;
+ info->updated_time.tv_sec = rec->new_objectv->pv_ctime_sec;
+ info->updated_time.tv_nsec = rec->new_objectv->pv_ctime_nsec;
kmlreint_pre_secure(rec, dir, &saved_ctxt);
dev = rec->rdev ?: MKDEV(rec->major, rec->minor);
@@ -262,7 +270,8 @@ static int reint_rename(struct kml_rec *
ENTRY;
CDEBUG (D_KML, "=====REINT_RENAME::%s -> %s\n", rec->path, rec->target);
- info->updated_time = rec->new_objectv->pv_mtime;
+ info->updated_time.tv_sec = rec->new_objectv->pv_mtime_sec;
+ info->updated_time.tv_nsec = rec->new_objectv->pv_mtime_nsec;
kmlreint_pre_secure(rec, dir, &saved_ctxt);
error = lento_rename(rec->path, rec->target, info);
pop_ctxt(&saved_ctxt);
@@ -287,7 +296,8 @@ static int reint_rmdir(struct kml_rec *r
}
CDEBUG (D_KML, "=====REINT_RMDIR::%s\n", path);
- info->updated_time = rec->new_parentv->pv_mtime;
+ info->updated_time.tv_sec = rec->new_parentv->pv_mtime_sec;
+ info->updated_time.tv_nsec = rec->new_parentv->pv_mtime_nsec;
kmlreint_pre_secure(rec, dir, &saved_ctxt);
error = lento_rmdir(path, info);
pop_ctxt(&saved_ctxt);
@@ -311,8 +321,10 @@ static int reint_setattr(struct kml_rec
iattr.ia_uid = (uid_t)rec->uid;
iattr.ia_gid = (gid_t)rec->gid;
iattr.ia_size = (off_t)rec->size;
- iattr.ia_ctime = (time_t)rec->ctime;
- iattr.ia_mtime = (time_t)rec->mtime;
+ iattr.ia_ctime.tv_sec = rec->ctime_sec;
+ iattr.ia_ctime.tv_nsec = rec->ctime_nsec;
+ iattr.ia_mtime.tv_sec = rec->mtime_sec;
+ iattr.ia_mtime.tv_nsec = rec->mtime_nsec;
iattr.ia_atime = iattr.ia_mtime; /* We don't track atimes. */
iattr.ia_attr_flags = rec->flags;
@@ -334,7 +346,8 @@ static int reint_symlink(struct kml_rec
ENTRY;
CDEBUG (D_KML, "=====REINT_SYMLINK::%s -> %s\n", rec->path, rec->target);
- info->updated_time = rec->new_objectv->pv_ctime;
+ info->updated_time.tv_sec = rec->new_objectv->pv_ctime_sec;
+ info->updated_time.tv_nsec = rec->new_objectv->pv_ctime_nsec;
kmlreint_pre_secure(rec, dir, &saved_ctxt);
error = lento_symlink(rec->target, rec->path, info);
pop_ctxt(&saved_ctxt);
@@ -359,7 +372,8 @@ static int reint_unlink(struct kml_rec *
}
CDEBUG (D_KML, "=====REINT_UNLINK::%s\n", path);
- info->updated_time = rec->new_parentv->pv_mtime;
+ info->updated_time.tv_sec = rec->new_parentv->pv_mtime_sec;
+ info->updated_time.tv_nsec = rec->new_parentv->pv_mtime_nsec;
kmlreint_pre_secure(rec, dir, &saved_ctxt);
error = lento_unlink(path, info);
pop_ctxt(&saved_ctxt);
--- linux-2.5.50/fs/intermezzo/kml_unpack.c~intermezzo Tue Dec 10 20:53:33 2002
+++ linux-2.5.50-root/fs/intermezzo/kml_unpack.c Tue Dec 10 21:12:16 2002
@@ -67,8 +67,10 @@ int kml_unpack_version(struct presto_ver
UNLOGP(*ver, struct presto_version, ptr, end);
pv = *ver;
- pv->pv_mtime = NTOH__u64(pv->pv_mtime);
- pv->pv_ctime = NTOH__u64(pv->pv_ctime);
+ pv->pv_mtime_sec = NTOH__u32(pv->pv_mtime_sec);
+ pv->pv_mtime_nsec = NTOH__u32(pv->pv_mtime_nsec);
+ pv->pv_ctime_sec = NTOH__u32(pv->pv_ctime_sec);
+ pv->pv_ctime_nsec = NTOH__u32(pv->pv_ctime_nsec);
pv->pv_size = NTOH__u64(pv->pv_size);
*buf = ptr;
@@ -247,8 +249,10 @@ static int kml_unpack_setattr(struct kml
LUNLOGV(rec->uid, __u32, ptr, end);
LUNLOGV(rec->gid, __u32, ptr, end);
LUNLOGV(rec->size, __u64, ptr, end);
- LUNLOGV(rec->mtime, __u64, ptr, end);
- LUNLOGV(rec->ctime, __u64, ptr, end);
+ LUNLOGV(rec->mtime_sec, __u32, ptr, end);
+ LUNLOGV(rec->mtime_nsec, __u32, ptr, end);
+ LUNLOGV(rec->ctime_sec, __u32, ptr, end);
+ LUNLOGV(rec->ctime_nsec, __u32, ptr, end);
LUNLOGV(rec->flags, __u32, ptr, end);
LUNLOGV(rec->old_mode, __u32, ptr, end);
LUNLOGV(rec->old_rdev, __u32, ptr, end);
--- linux-2.5.50/fs/intermezzo/presto.c~intermezzo Tue Dec 10 20:53:33 2002
+++ linux-2.5.50-root/fs/intermezzo/presto.c Tue Dec 10 21:13:20 2002
@@ -627,8 +627,10 @@ int presto_put_permit(struct inode * ino
void presto_getversion(struct presto_version * presto_version,
struct inode * inode)
{
- presto_version->pv_mtime = (__u64)inode->i_mtime;
- presto_version->pv_ctime = (__u64)inode->i_ctime;
+ presto_version->pv_mtime_sec = inode->i_mtime.tv_sec;
+ presto_version->pv_mtime_nsec = inode->i_mtime.tv_nsec;
+ presto_version->pv_ctime_sec = inode->i_ctime.tv_sec;
+ presto_version->pv_ctime_nsec = inode->i_ctime.tv_nsec;
presto_version->pv_size = (__u64)inode->i_size;
}
--- linux-2.5.50/fs/intermezzo/replicator.c~intermezzo Tue Dec 10 20:53:33 2002
+++ linux-2.5.50-root/fs/intermezzo/replicator.c Tue Dec 10 21:15:33 2002
@@ -29,7 +29,8 @@
#include <asm/uaccess.h>
#include <linux/errno.h>
-
+#include <linux/fs.h>
+#include <linux/fsfilter.h>
#include <linux/intermezzo_fs.h>
/*
--- linux-2.5.50/fs/intermezzo/vfs.c~intermezzo Tue Dec 10 20:53:33 2002
+++ linux-2.5.50-root/fs/intermezzo/vfs.c Tue Dec 10 21:17:06 2002
@@ -186,7 +186,7 @@ inline void presto_debug_fail_blkdev(str
if (errorval && errorval == (long)value && !is_read_only(dev)) {
CDEBUG(D_SUPER, "setting device %s read only\n", kdevname(dev));
- BLKDEV_FAIL(dev, 1);
+ BLKDEV_FAIL(kdev_val(dev), 1);
izo_channels[minor].uc_errorval = -kdev_val(dev);
}
}
@@ -475,7 +475,7 @@ int lento_setattr(const char *name, stru
name, iattr->ia_valid, iattr->ia_mode, iattr->ia_uid,
iattr->ia_gid, iattr->ia_size);
CDEBUG(D_PIOCTL, "atime %#lx, mtime %#lx, ctime %#lx, attr_flags %#x\n",
- iattr->ia_atime, iattr->ia_mtime.tv_sec, iattr->ia_ctime.tv_sec,
+ iattr->ia_atime.tv_sec, iattr->ia_mtime.tv_sec, iattr->ia_ctime.tv_sec,
iattr->ia_attr_flags);
CDEBUG(D_PIOCTL, "offset %d, recno %d, flags %#x\n",
info->slot_offset, info->recno, info->flags);
--- /dev/null Fri Aug 30 17:31:37 2002
+++ linux-2.5.50-root/include/linux/fsfilter.h Wed Nov 27 15:35:47 2002
@@ -0,0 +1,134 @@
+/* -*- mode: c; c-basic-offset: 8; indent-tabs-mode: nil; -*-
+ * vim:expandtab:shiftwidth=8:tabstop=8:
+ */
+
+#ifndef __FILTER_H_
+#define __FILTER_H_ 1
+
+#ifdef __KERNEL__
+
+/* cachetype.c */
+
+/*
+ * it is important that things like inode, super and file operations
+ * for intermezzo are not defined statically. If methods are NULL
+ * the VFS takes special action based on that. Given that different
+ * cache types have NULL ops at different slots, we must install opeation
+ * talbes for InterMezzo with NULL's in the same spot
+ */
+
+struct filter_ops {
+ struct super_operations filter_sops;
+
+ struct inode_operations filter_dir_iops;
+ struct inode_operations filter_file_iops;
+ struct inode_operations filter_sym_iops;
+
+ struct file_operations filter_dir_fops;
+ struct file_operations filter_file_fops;
+ struct file_operations filter_sym_fops;
+
+ struct dentry_operations filter_dentry_ops;
+};
+
+struct cache_ops {
+ /* operations on the file store */
+ struct super_operations *cache_sops;
+
+ struct inode_operations *cache_dir_iops;
+ struct inode_operations *cache_file_iops;
+ struct inode_operations *cache_sym_iops;
+
+ struct file_operations *cache_dir_fops;
+ struct file_operations *cache_file_fops;
+ struct file_operations *cache_sym_fops;
+
+ struct dentry_operations *cache_dentry_ops;
+};
+
+
+#define FILTER_DID_SUPER_OPS 0x1
+#define FILTER_DID_INODE_OPS 0x2
+#define FILTER_DID_FILE_OPS 0x4
+#define FILTER_DID_DENTRY_OPS 0x8
+#define FILTER_DID_DEV_OPS 0x10
+#define FILTER_DID_SYMLINK_OPS 0x20
+#define FILTER_DID_DIR_OPS 0x40
+
+struct filter_fs {
+ int o_flags;
+ struct filter_ops o_fops;
+ struct cache_ops o_caops;
+ struct journal_ops *o_trops;
+ struct snapshot_ops *o_snops;
+};
+
+#define FILTER_FS_TYPES 6
+#define FILTER_FS_EXT2 0
+#define FILTER_FS_EXT3 1
+#define FILTER_FS_REISERFS 2
+#define FILTER_FS_XFS 3
+#define FILTER_FS_OBDFS 4
+#define FILTER_FS_TMPFS 5
+extern struct filter_fs filter_oppar[FILTER_FS_TYPES];
+
+struct filter_fs *filter_get_filter_fs(const char *cache_type);
+void filter_setup_journal_ops(struct filter_fs *ops, char *cache_type);
+inline struct super_operations *filter_c2usops(struct filter_fs *cache);
+inline struct inode_operations *filter_c2ufiops(struct filter_fs *cache);
+inline struct inode_operations *filter_c2udiops(struct filter_fs *cache);
+inline struct inode_operations *filter_c2usiops(struct filter_fs *cache);
+inline struct file_operations *filter_c2uffops(struct filter_fs *cache);
+inline struct file_operations *filter_c2udfops(struct filter_fs *cache);
+inline struct file_operations *filter_c2usfops(struct filter_fs *cache);
+inline struct super_operations *filter_c2csops(struct filter_fs *cache);
+inline struct inode_operations *filter_c2cfiops(struct filter_fs *cache);
+inline struct inode_operations *filter_c2cdiops(struct filter_fs *cache);
+inline struct inode_operations *filter_c2csiops(struct filter_fs *cache);
+inline struct file_operations *filter_c2cffops(struct filter_fs *cache);
+inline struct file_operations *filter_c2cdfops(struct filter_fs *cache);
+inline struct file_operations *filter_c2csfops(struct filter_fs *cache);
+inline struct dentry_operations *filter_c2cdops(struct filter_fs *cache);
+inline struct dentry_operations *filter_c2udops(struct filter_fs *cache);
+
+void filter_setup_super_ops(struct filter_fs *cache, struct super_operations *cache_ops, struct super_operations *filter_sops);
+void filter_setup_dir_ops(struct filter_fs *cache, struct inode *cache_inode, struct inode_operations *filter_iops, struct file_operations *ffops);
+void filter_setup_file_ops(struct filter_fs *cache, struct inode *cache_inode, struct inode_operations *filter_iops, struct file_operations *filter_op);
+void filter_setup_symlink_ops(struct filter_fs *cache, struct inode *cache_inode, struct inode_operations *filter_iops, struct file_operations *filter_op);
+void filter_setup_dentry_ops(struct filter_fs *cache, struct dentry_operations *cache_dop, struct dentry_operations *filter_dop);
+
+
+#define PRESTO_DEBUG
+#ifdef PRESTO_DEBUG
+/* debugging masks */
+#define D_SUPER 1
+#define D_INODE 2 /* print entry and exit into procedure */
+#define D_FILE 4
+#define D_CACHE 8 /* cache debugging */
+#define D_MALLOC 16 /* print malloc, de-alloc information */
+#define D_JOURNAL 32
+#define D_UPCALL 64 /* up and downcall debugging */
+#define D_PSDEV 128
+#define D_PIOCTL 256
+#define D_SPECIAL 512
+#define D_TIMING 1024
+#define D_DOWNCALL 2048
+
+#define FDEBUG(mask, format, a...) \
+ do { \
+ if (filter_debug & mask) { \
+ printk("(%s,l. %d): ", __FUNCTION__, __LINE__); \
+ printk(format, ##a); } \
+ } while (0)
+
+#define FENTRY \
+ if(filter_print_entry) \
+ printk("Process %d entered %s\n", current->pid, __FUNCTION__)
+
+#define FEXIT \
+ if(filter_print_entry) \
+ printk("Process %d leaving %s at %d\n", current->pid, \
+ __FUNCTION__,__LINE__)
+#endif
+#endif
+#endif
--- linux-2.5.50/include/linux/intermezzo_fs.h~intermezzo Tue Dec 10 20:53:33 2002
+++ linux-2.5.50-root/include/linux/intermezzo_fs.h Tue Dec 10 20:53:33 2002
@@ -39,7 +39,7 @@ typedef __u8 uuid_t[16];
struct lento_vfs_context {
__u64 kml_offset;
- __u64 updated_time;
+ struct timespec updated_time;
__u64 remote_ino;
__u64 remote_generation;
__u32 slot_offset;
--- /dev/null Fri Aug 30 17:31:37 2002
+++ linux-2.5.50-root/include/linux/intermezzo_idl.h Tue Dec 10 21:10:33 2002
@@ -0,0 +1,304 @@
+/* -*- mode: c; c-basic-offset: 8; indent-tabs-mode: nil; -*-
+ * vim:expandtab:shiftwidth=8:tabstop=8:
+ *
+ * Copyright (C) 2001, 2002 Cluster File Systems, Inc.
+ * Copyright (C) 2001 Tacit Networks, Inc.
+ *
+ * This file is part of InterMezzo, http://www.inter-mezzo.org.
+ *
+ * InterMezzo is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ *
+ * InterMezzo is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with InterMezzo; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __INTERMEZZO_IDL_H__
+#define __INTERMEZZO_IDL_H__
+
+#include <linux/ioctl.h>
+#include <linux/types.h>
+
+/* this file contains all data structures used in InterMezzo's interfaces:
+ * - upcalls
+ * - ioctl's
+ * - KML records
+ * - RCVD records
+ * - rpc's
+ */
+
+/* UPCALL */
+#define INTERMEZZO_MINOR 248
+
+
+#define IZO_UPC_VERSION 0x00010002
+#define IZO_UPC_PERMIT 1
+#define IZO_UPC_CONNECT 2
+#define IZO_UPC_GO_FETCH_KML 3
+#define IZO_UPC_OPEN 4
+#define IZO_UPC_REVOKE_PERMIT 5
+#define IZO_UPC_KML 6
+#define IZO_UPC_BACKFETCH 7
+#define IZO_UPC_KML_TRUNC 8
+#define IZO_UPC_SET_KMLSIZE 9
+#define IZO_UPC_BRANCH_UNDO 10
+#define IZO_UPC_BRANCH_REDO 11
+#define IZO_UPC_GET_FILEID 12
+#define IZO_UPC_CLIENT_MAKE_BRANCH 13
+#define IZO_UPC_SERVER_MAKE_BRANCH 14
+#define IZO_UPC_REPSTATUS 15
+
+#define IZO_UPC_LARGEST_OPCODE 15
+
+struct izo_upcall_hdr {
+ __u32 u_len;
+ __u32 u_version;
+ __u32 u_opc;
+ __u32 u_uniq;
+ __u32 u_pid;
+ __u32 u_uid;
+ __u32 u_pathlen;
+ __u32 u_fsetlen;
+ __u64 u_offset;
+ __u64 u_length;
+ __u32 u_first_recno;
+ __u32 u_last_recno;
+ __u32 u_async;
+ __u32 u_reclen;
+ __u8 u_uuid[16];
+};
+
+/* This structure _must_ sit at the beginning of the buffer */
+struct izo_upcall_resp {
+ __u32 opcode;
+ __u32 unique;
+ __u32 result;
+};
+
+
+/* IOCTL */
+
+#define IZO_IOCTL_VERSION 0x00010003
+
+/* maximum size supported for ioc_pbuf1 */
+#define KML_MAX_BUF (64*1024)
+
+struct izo_ioctl_hdr {
+ __u32 ioc_len;
+ __u32 ioc_version;
+};
+
+struct izo_ioctl_data {
+ __u32 ioc_len;
+ __u32 ioc_version;
+ __u32 ioc_izodev;
+ __u32 ioc_kmlrecno;
+ __u64 ioc_kmlsize;
+ __u32 ioc_flags;
+ __s32 ioc_inofd;
+ __u64 ioc_ino;
+ __u64 ioc_generation;
+ __u32 ioc_mark_what;
+ __u32 ioc_and_flag;
+ __u32 ioc_or_flag;
+ __u32 ioc_dev;
+ __u32 ioc_offset;
+ __u32 ioc_slot;
+ __u64 ioc_uid;
+ __u8 ioc_uuid[16];
+
+ __u32 ioc_inllen1; /* path */
+ char *ioc_inlbuf1;
+ __u32 ioc_inllen2; /* fileset */
+ char *ioc_inlbuf2;
+
+ __u32 ioc_plen1; /* buffers in user space (KML) */
+ char *ioc_pbuf1;
+ __u32 ioc_plen2; /* buffers in user space (KML) */
+ char *ioc_pbuf2;
+
+ char ioc_bulk[0];
+};
+
+#define IZO_IOC_DEVICE _IOW ('p',0x50, void *)
+#define IZO_IOC_REINTKML _IOW ('p',0x51, void *)
+#define IZO_IOC_GET_RCVD _IOW ('p',0x52, void *)
+#define IZO_IOC_SET_IOCTL_UID _IOW ('p',0x53, void *)
+#define IZO_IOC_GET_KML_SIZE _IOW ('p',0x54, void *)
+#define IZO_IOC_PURGE_FILE_DATA _IOW ('p',0x55, void *)
+#define IZO_IOC_CONNECT _IOW ('p',0x56, void *)
+#define IZO_IOC_GO_FETCH_KML _IOW ('p',0x57, void *)
+#define IZO_IOC_MARK _IOW ('p',0x58, void *)
+#define IZO_IOC_CLEAR_FSET _IOW ('p',0x59, void *)
+#define IZO_IOC_CLEAR_ALL_FSETS _IOW ('p',0x60, void *)
+#define IZO_IOC_SET_FSET _IOW ('p',0x61, void *)
+#define IZO_IOC_REVOKE_PERMIT _IOW ('p',0x62, void *)
+#define IZO_IOC_SET_KMLSIZE _IOW ('p',0x63, void *)
+#define IZO_IOC_CLIENT_MAKE_BRANCH _IOW ('p',0x64, void *)
+#define IZO_IOC_SERVER_MAKE_BRANCH _IOW ('p',0x65, void *)
+#define IZO_IOC_BRANCH_UNDO _IOW ('p',0x66, void *)
+#define IZO_IOC_BRANCH_REDO _IOW ('p',0x67, void *)
+#define IZO_IOC_SET_PID _IOW ('p',0x68, void *)
+#define IZO_IOC_SET_CHANNEL _IOW ('p',0x69, void *)
+#define IZO_IOC_GET_CHANNEL _IOW ('p',0x70, void *)
+#define IZO_IOC_GET_FILEID _IOW ('p',0x71, void *)
+#define IZO_IOC_ADJUST_LML _IOW ('p',0x72, void *)
+#define IZO_IOC_SET_FILEID _IOW ('p',0x73, void *)
+#define IZO_IOC_REPSTATUS _IOW ('p',0x74, void *)
+
+/* marking flags for fsets */
+#define FSET_CLIENT_RO 0x00000001
+#define FSET_LENTO_RO 0x00000002
+#define FSET_HASPERMIT 0x00000004 /* we have a permit to WB */
+#define FSET_INSYNC 0x00000008 /* this fileset is in sync */
+#define FSET_PERMIT_WAITING 0x00000010 /* Lento is waiting for permit */
+#define FSET_STEAL_PERMIT 0x00000020 /* take permit if Lento is dead */
+#define FSET_JCLOSE_ON_WRITE 0x00000040 /* Journal closes on writes */
+#define FSET_DATA_ON_DEMAND 0x00000080 /* update data on file_open() */
+#define FSET_PERMIT_EXCLUSIVE 0x00000100 /* only one permitholder allowed */
+#define FSET_HAS_BRANCHES 0x00000200 /* this fileset contains branches */
+#define FSET_IS_BRANCH 0x00000400 /* this fileset is a branch */
+#define FSET_FLAT_BRANCH 0x00000800 /* this fileset is ROOT with branches */
+
+/* what to mark indicator (ioctl parameter) */
+#define MARK_DENTRY 101
+#define MARK_FSET 102
+#define MARK_CACHE 103
+#define MARK_GETFL 104
+
+/* KML */
+
+#define KML_MAJOR_VERSION 0x00010000
+#define KML_MINOR_VERSION 0x00000002
+#define KML_OPCODE_NOOP 0
+#define KML_OPCODE_CREATE 1
+#define KML_OPCODE_MKDIR 2
+#define KML_OPCODE_UNLINK 3
+#define KML_OPCODE_RMDIR 4
+#define KML_OPCODE_CLOSE 5
+#define KML_OPCODE_SYMLINK 6
+#define KML_OPCODE_RENAME 7
+#define KML_OPCODE_SETATTR 8
+#define KML_OPCODE_LINK 9
+#define KML_OPCODE_OPEN 10
+#define KML_OPCODE_MKNOD 11
+#define KML_OPCODE_WRITE 12
+#define KML_OPCODE_RELEASE 13
+#define KML_OPCODE_TRUNC 14
+#define KML_OPCODE_SETEXTATTR 15
+#define KML_OPCODE_DELEXTATTR 16
+#define KML_OPCODE_KML_TRUNC 17
+#define KML_OPCODE_GET_FILEID 18
+#define KML_OPCODE_NUM 19
+/* new stuff */
+struct presto_version {
+ __u32 pv_mtime_sec;
+ __u32 pv_mtime_nsec;
+ __u32 pv_ctime_sec;
+ __u32 pv_ctime_nsec;
+ __u64 pv_size;
+};
+
+struct kml_prefix_hdr {
+ __u32 len;
+ __u32 version;
+ __u32 pid;
+ __u32 auid;
+ __u32 fsuid;
+ __u32 fsgid;
+ __u32 opcode;
+ __u32 ngroups;
+};
+
+struct kml_prefix {
+ struct kml_prefix_hdr *hdr;
+ __u32 *groups;
+};
+
+struct kml_suffix {
+ __u32 prevrec;
+ __u32 recno;
+ __u32 time;
+ __u32 len;
+};
+
+struct kml_rec {
+ char *buf;
+ struct kml_prefix prefix;
+ __u64 offset;
+ char *path;
+ int pathlen;
+ char *name;
+ int namelen;
+ char *target;
+ int targetlen;
+ struct presto_version *old_objectv;
+ struct presto_version *new_objectv;
+ struct presto_version *old_parentv;
+ struct presto_version *new_parentv;
+ struct presto_version *old_targetv;
+ struct presto_version *new_targetv;
+ __u32 valid;
+ __u32 mode;
+ __u32 uid;
+ __u32 gid;
+ __u64 size;
+ __u32 mtime_sec;
+ __u32 mtime_nsec;
+ __u32 ctime_sec;
+ __u32 ctime_nsec;
+ __u32 flags;
+ __u32 ino;
+ __u32 rdev;
+ __u32 major;
+ __u32 minor;
+ __u32 generation;
+ __u32 old_mode;
+ __u32 old_rdev;
+ __u64 old_uid;
+ __u64 old_gid;
+ char *old_target;
+ int old_targetlen;
+ struct kml_suffix *suffix;
+};
+
+
+/* RCVD */
+
+/* izo_rcvd_rec fills the .intermezzo/fset/last_rcvd file and provides data about
+ * our view of reintegration offsets for a given peer.
+ *
+ * The only exception is the last_rcvd record which has a UUID consisting of all
+ * zeroes; this record's lr_local_offset field is the logical byte offset of our
+ * KML, which is updated when KML truncation takes place. All other fields are
+ * reserved. */
+
+/* XXX - document how clean shutdowns are recorded */
+
+struct izo_rcvd_rec {
+ __u8 lr_uuid[16]; /* which peer? */
+ __u64 lr_remote_recno; /* last confirmed remote recno */
+ __u64 lr_remote_offset; /* last confirmed remote offset */
+ __u64 lr_local_recno; /* last locally reinted recno */
+ __u64 lr_local_offset; /* last locally reinted offset */
+ __u64 lr_last_ctime; /* the largest ctime that has reintegrated */
+};
+
+/* Cache purge database
+ *
+ * Each DB entry is this structure followed by the path name, no trailing NUL. */
+struct izo_purge_entry {
+ __u64 p_atime;
+ __u32 p_pathlen;
+};
+
+/* RPC */
+
+#endif
--- /dev/null Fri Aug 30 17:31:37 2002
+++ linux-2.5.50-root/include/linux/intermezzo_lib.h Tue Dec 10 20:53:33 2002
@@ -0,0 +1,168 @@
+/* -*- mode: c; c-basic-offset: 8; indent-tabs-mode: nil; -*-
+ * vim:expandtab:shiftwidth=8:tabstop=8:
+ *
+ * Copyright (C) 2001 Cluster File Systems, Inc. <braam@clusterfs.com>
+ *
+ * This file is part of InterMezzo, http://www.inter-mezzo.org.
+ *
+ * InterMezzo is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ *
+ * InterMezzo is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with InterMezzo; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Data structures unpacking/packing macros & inlines
+ *
+ */
+
+#ifndef _INTERMEZZO_LIB_H
+#define _INTERMEZZO_LIB_H
+
+#ifdef __KERNEL__
+# include <linux/types.h>
+#else
+# include <string.h>
+# include <sys/types.h>
+#endif
+
+#undef MIN
+#define MIN(a,b) (((a)<(b)) ? (a): (b))
+#undef MAX
+#define MAX(a,b) (((a)>(b)) ? (a): (b))
+#define MKSTR(ptr) ((ptr))? (ptr) : ""
+
+static inline int size_round (int val)
+{
+ return (val + 3) & (~0x3);
+}
+
+static inline int size_round0(int val)
+{
+ if (!val)
+ return 0;
+ return (val + 1 + 3) & (~0x3);
+}
+
+static inline size_t round_strlen(char *fset)
+{
+ return size_round(strlen(fset) + 1);
+}
+
+#ifdef __KERNEL__
+# define NTOH__u32(var) le32_to_cpu(var)
+# define NTOH__u64(var) le64_to_cpu(var)
+# define HTON__u32(var) cpu_to_le32(var)
+# define HTON__u64(var) cpu_to_le64(var)
+#else
+# include <glib.h>
+# define NTOH__u32(var) GUINT32_FROM_LE(var)
+# define NTOH__u64(var) GUINT64_FROM_LE(var)
+# define HTON__u32(var) GUINT32_TO_LE(var)
+# define HTON__u64(var) GUINT64_TO_LE(var)
+#endif
+
+/*
+ * copy sizeof(type) bytes from pointer to var and move ptr forward.
+ * return EFAULT if pointer goes beyond end
+ */
+#define UNLOGV(var,type,ptr,end) \
+do { \
+ var = *(type *)ptr; \
+ ptr += sizeof(type); \
+ if (ptr > end ) \
+ return -EFAULT; \
+} while (0)
+
+/* the following two macros convert to little endian */
+/* type MUST be __u32 or __u64 */
+#define LUNLOGV(var,type,ptr,end) \
+do { \
+ var = NTOH##type(*(type *)ptr); \
+ ptr += sizeof(type); \
+ if (ptr > end ) \
+ return -EFAULT; \
+} while (0)
+
+/* now log values */
+#define LOGV(var,type,ptr) \
+do { \
+ *((type *)ptr) = var; \
+ ptr += sizeof(type); \
+} while (0)
+
+/* and in network order */
+#define LLOGV(var,type,ptr) \
+do { \
+ *((type *)ptr) = HTON##type(var); \
+ ptr += sizeof(type); \
+} while (0)
+
+
+/*
+ * set var to point at (type *)ptr, move ptr forward with sizeof(type)
+ * return from function with EFAULT if ptr goes beyond end
+ */
+#define UNLOGP(var,type,ptr,end) \
+do { \
+ var = (type *)ptr; \
+ ptr += sizeof(type); \
+ if (ptr > end ) \
+ return -EFAULT; \
+} while (0)
+
+#define LOGP(var,type,ptr) \
+do { \
+ memcpy(ptr, var, sizeof(type)); \
+ ptr += sizeof(type); \
+} while (0)
+
+/*
+ * set var to point at (char *)ptr, move ptr forward by size_round(len);
+ * return from function with EFAULT if ptr goes beyond end
+ */
+#define UNLOGL(var,type,len,ptr,end) \
+do { \
+ if (len == 0) \
+ var = (type *)0; \
+ else { \
+ var = (type *)ptr; \
+ ptr += size_round(len * sizeof(type)); \
+ } \
+ if (ptr > end ) \
+ return -EFAULT; \
+} while (0)
+
+#define UNLOGL0(var,type,len,ptr,end) \
+do { \
+ UNLOGL(var,type,len+1,ptr,end); \
+ if ( *((char *)ptr - size_round(len+1) + len) != '\0') \
+ return -EFAULT; \
+} while (0)
+
+#define LOGL(var,len,ptr) \
+do { \
+ size_t __fill = size_round(len); \
+ /* Prevent data leakage. */ \
+ if (__fill > 0) \
+ memset((char *)ptr, 0, __fill); \
+ memcpy((char *)ptr, (const char *)var, len); \
+ ptr += __fill; \
+} while (0)
+
+#define LOGL0(var,len,ptr) \
+do { \
+ if (!len) break; \
+ memcpy((char *)ptr, (const char *)var, len); \
+ *((char *)(ptr) + len) = 0; \
+ ptr += size_round(len + 1); \
+} while (0)
+
+#endif /* _INTERMEZZO_LIB_H */
+
_
^ 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.