From: Doug Meyer
Here we add the PCI quirk for the Microsemi Switchtec parts to allow
DMA access via non-transparent bridging to work when the IOMMU is
turned on.
This exclusively addresses the ability of a remote NT endpoint to
perform DMA accesses through the locally enumerated NT endpoint.
Ot
From: Doug Meyer
This is the first of two patches to implement a PCI quirk which will
allow the Switchtec NTB code to work with the IOMMU turned on.
Here, the Microsemi Switchtec PCI vendor and device ID constants are
moved to the canonical location in pci_ids.h. Also, Microsemi class
constants
From: Doug Meyer
This is a resend of the patch series to enable Microsemi Switchtec
NTB configurations to run with the IOMMU in the hosts turned on.
Because of the nature PCI Quirk implementation, it was preferable
to migrate the Microsemi PCI vendor and device definitions to the
Linux canonical
From: Doug Meyer
Here we add the PCI quirk for the Microsemi Switchtec parts to allow
non-transparent bridging to work when the IOMMU is turned on.
When a requestor on one NT endpoint accesses memory on another NT
endpoint, it does this via a devfn proxy ID. Proxy IDs are uniquely
assigned on a
From: Doug Meyer
This is the first of two patches to implement a PCI quirk which will
allow the Switchtec NTB code to work with the IOMMU turned on.
Here, the Microsemi Switchtec PCI vendor and device ID constants are
moved to the canonical location in pci_ids.h. Also, Microsemi class
constants
From: Doug Meyer
This patch series addresses the need to be able to run Microsemi
Switchtec NTB configurations with the IOMMU in the hosts turned on.
Because of the nature PCI Quirk implementation, it was preferable
to migrate the Microsemi PCI vendor and device definitions to the
Linux canonical
From: Doug Meyer
This resolves a bug which may incorrectly configure the peer host's
LUT for shared memory window access. The code was using the local
host's first BAR number, rather than the peer hosts's first BAR
number, to determine what peer NT control register to program.
The bug will cause
In article <[EMAIL PROTECTED]> you write:
> On Thu, 01 Feb 2001, Nils Rennebarth wrote:
> > Feb 1 12:58:56 obelix kernel: NAT: 0 dropping untracked packet
> ce767600 1 129.69.22.21 -> 224.0.0.2
>
> It means that your box drops multicast administrative packets on the
> floor.
I'm getting the occ
In article <[EMAIL PROTECTED]> you write:
> On Tue, 30 Jan 2001 14:15:20 -0600 (CST),
> Jason Michaelson <[EMAIL PROTECTED]> wrote:
> >Greetings. I've just procured myself a copy of 2.4.1, and tried to build
> >it. At the tail end of a make modules_install, the following error occurs:
> >
> >depm
The kernel always says:
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
at boot time. How would I know if it's safe to say idebus=66? The
documentation is fairly vague on this.
Thanks,
Dave
--
David M. Meyer
[EMAIL PROTECTED]
-
To unsubscribe from this li
According to Grover, Andrew:
> This is pretty weird, since the latest ACPI update went in pre10, and it was
> pretty minor. That you are saying problems started in pre8 implies this is
> not a problem with the ACPI driver, but something else.. hmm..
>
> So it worked in pre7 and broke in pre8?
I
I'm still having ACPI difficulties with Linux-2.4.1-pre10 on my
system. Up to (and including) Linux-2.4.0, it worked fine; the kernel
reported:
Jan 14 22:53:05 jhereg kernel: ACPI: System description tables found
Jan 14 22:53:05 jhereg kernel: ACPI: System description tables loaded
Jan 14 22:53:
,&buf);
printf("stat original file: %d\n",buf.st_size);
symlink("stattest.c","a_symlink");
stat("a_symlink",&buf);
printf("stat symlink: %d\n",buf.st_size);
lstat("a_symlink",&buf);
In article <9463fj$gsq$[EMAIL PROTECTED]> you write:
> Basically, the _only_ think you should depend on is that st_size
> contains:
> - for regular files, the size of the file in bytes
> - for symlinks, the length of the symlink.
I don't think this is right - for a symlink, stat should return t
Between 2.4.0-test10 and 2.4.0 enough stuff changed that I can't get
the OpenGL NVIDIA_kernel module compiled and linked properly. Has
anyone else taken a shot at this?
I realize this is a little bit OT, since it's something that nvidia
ought to be handling, but thus far they've failed to respon
I'm getting an error message from linux-2.4.0 which I wasn't getting
with linux-2.4.0-test10. I have an MS-6167 motherboard. Both kernels
report
Jan 5 16:39:17 jhereg kernel: BIOS-e820: d000 @ 0fff3000 (ACPI
data)
Jan 5 16:39:17 jhereg kernel: BIOS-e820: 300
In article <[EMAIL PROTECTED]> you write:
> well.. silly me :)... I did have SMP enabled (it appears that's the
> default option? but anyways...now I get a whole slew of other
> errors which I'm not going to go into right now, cos that would
> involve spamming everyone with about 4 pages of sp
17 matches
Mail list logo
