Hey.
Perhaps anyone can help with the following, which is a problem at a
mass storage system cluster at the physics faculty here:
The cluster consists of 40 nodes all running Debian stable with a
4.9.130 kernel serving some ~3 PiB storage via 10GbE networking.
Part of the nodes are some Dell
Hey.
I'm seeing these errors:
Jun 09 21:13:22 heisenberg kernel: sd 6:0:0:0: [sdb] Unaligned partial
completion (resid=16, sector_sz=512)
Jun 09 21:13:22 heisenberg kernel: sd 6:0:0:0: [sdb] tag#0 FAILED Result:
hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun 09 21:13:22 heisenberg kernel: sd
Hey.
I'm seeing these errors:
Jun 09 21:13:22 heisenberg kernel: sd 6:0:0:0: [sdb] Unaligned partial
completion (resid=16, sector_sz=512)
Jun 09 21:13:22 heisenberg kernel: sd 6:0:0:0: [sdb] tag#0 FAILED Result:
hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun 09 21:13:22 heisenberg kernel: sd
Hey.
Perhaps someone can help me with this.
I got a brand new notebook from the university, a Fujitsu U757[0][1],
with a 2 core Kaby Lake (i7-7600U) and 32GB RAM.
It runs Debian unstable, that is as of now kernel 4.13.4.
Even at pretty simple tasks (just some VM running) and a bit more, the
Hey.
Perhaps someone can help me with this.
I got a brand new notebook from the university, a Fujitsu U757[0][1],
with a 2 core Kaby Lake (i7-7600U) and 32GB RAM.
It runs Debian unstable, that is as of now kernel 4.13.4.
Even at pretty simple tasks (just some VM running) and a bit more, the
Hey.
I bough a USB3.0 ExpressCard from StarTech[0] which is apparently[1]
based on the NEC uPD720200.
Using a kernel 4.2.6 on amd64, the System is Debian sid, the following
happens when I plug the card:
kernel logs show:
Nov 21 17:15:22 heisenberg kernel: [ 102.387452] pci :01:00.0:
Hey.
I bough a USB3.0 ExpressCard from StarTech[0] which is apparently[1]
based on the NEC uPD720200.
Using a kernel 4.2.6 on amd64, the System is Debian sid, the following
happens when I plug the card:
kernel logs show:
Nov 21 17:15:22 heisenberg kernel: [ 102.387452] pci :01:00.0:
Hi Greg, Guenter and Chris.
Coming back to the stuff discussed previously[0].
Chris Eastwood has made most of these (i.e. LEDs and buttons, the
buzzers may work on at least some of the devices via some other serial
device) working (AFAIU based on the previously mentioned code at
Github[1]), he
Hi Greg, Guenter and Chris.
Coming back to the stuff discussed previously[0].
Chris Eastwood has made most of these (i.e. LEDs and buttons, the
buzzers may work on at least some of the devices via some other serial
device) working (AFAIU based on the previously mentioned code at
Github[1]), he
Oh and one more thing:
The QNAP driver seems to be able to do much more than just
LEDs/HDD-LEDs/buzzers/buttons... at least their symbols imply such,
like:
#define QNAP_IOCTL_SATA_UP 0x0100
#define QNAP_IOCTL_SATA_DOWN0x0200
#define QNAP_IOCTL_ESATA_UP 0x0300
#define
On Thu, 2013-06-20 at 14:42 -0700, Greg KH wrote:
> Also, do you have a pointer to the git tree for
> the hardware again, I can't seem to find it.
You mean a git repo for their driver? I don't think they have one...
just the big tarball with the patches integrated...
> I can dig through the
Hey Greg.
On Wed, 2013-06-19 at 19:59 -0700, Greg KH wrote:
> If you can dig the code out into a stand-alone form that I can make into
> a patch for the drivers/staging/ tree, I'll be glad to take it.
Well I don't think my kernel/hardware development skills are enough for
that... especially as
Hey Greg.
On Wed, 2013-06-19 at 19:59 -0700, Greg KH wrote:
If you can dig the code out into a stand-alone form that I can make into
a patch for the drivers/staging/ tree, I'll be glad to take it.
Well I don't think my kernel/hardware development skills are enough for
that... especially as
On Thu, 2013-06-20 at 14:42 -0700, Greg KH wrote:
Also, do you have a pointer to the git tree for
the hardware again, I can't seem to find it.
You mean a git repo for their driver? I don't think they have one...
just the big tarball with the patches integrated...
I can dig through the tree
Oh and one more thing:
The QNAP driver seems to be able to do much more than just
LEDs/HDD-LEDs/buzzers/buttons... at least their symbols imply such,
like:
#define QNAP_IOCTL_SATA_UP 0x0100
#define QNAP_IOCTL_SATA_DOWN0x0200
#define QNAP_IOCTL_ESATA_UP 0x0300
#define
On Sat, 2013-06-15 at 03:31 +0200, Christoph Anton Mitterer wrote:
> I wondered whether anyone knows, whether the kernel supports the
> LEDs/buttons/buzzer of Intel Atom based QNAP NAS like the TS-569 Pro?
I tried to find out some more information (and got some help there as
well)... see
On Sat, 2013-06-15 at 03:31 +0200, Christoph Anton Mitterer wrote:
I wondered whether anyone knows, whether the kernel supports the
LEDs/buttons/buzzer of Intel Atom based QNAP NAS like the TS-569 Pro?
I tried to find out some more information (and got some help there as
well)... seems I'm
Hi.
I wondered whether anyone knows, whether the kernel supports the
LEDs/buttons/buzzer of Intel Atom based QNAP NAS like the TS-569 Pro?
I got the two line LCD, which is a A125, working,...it can easily be
controlled via the serial device... but not the others.
Seems these are GPIO
Hi.
I wondered whether anyone knows, whether the kernel supports the
LEDs/buttons/buzzer of Intel Atom based QNAP NAS like the TS-569 Pro?
I got the two line LCD, which is a A125, working,...it can easily be
controlled via the serial device... but not the others.
Seems these are GPIO
On Sun, 2012-10-07 at 21:24 -0400, Theodore Ts'o wrote:
> I've looked at his message, I didn't see any justification for his
> concern/assertion. So I can't really comment on it since he didn't
> give any reason for his belief.
I asked him again[0] to be sure and he replied to have no reason to
On Sun, 2012-10-07 at 21:24 -0400, Theodore Ts'o wrote:
I've looked at his message, I didn't see any justification for his
concern/assertion. So I can't really comment on it since he didn't
give any reason for his belief.
I asked him again[0] to be sure and he replied to have no reason to
Hi Ted.
Thanks for your prompt reply.
On Thu, 2012-10-04 at 18:49 -0400, Theodore Ts'o wrote:
> It is impossible by design. Or specifically, /dev/random was designed
> so that it can be world-writeable, and an attacker can feed in any
> kind of input he or she wants, and it will not allow the
Hi Ted.
Thanks for your prompt reply.
On Thu, 2012-10-04 at 18:49 -0400, Theodore Ts'o wrote:
It is impossible by design. Or specifically, /dev/random was designed
so that it can be world-writeable, and an attacker can feed in any
kind of input he or she wants, and it will not allow the
Hi.
This is a question towards the crypto/entropy experts.
When seeding the kernels entropy cache (which is then ultimately used
for /dev/random), e.g. by (semi-)TRNGs like haveged[0],
audio-entropyd[1], Simtec’s Entropy Key[2] or friends... can one spoil
the randomness by that or is this
Hi.
This is a question towards the crypto/entropy experts.
When seeding the kernels entropy cache (which is then ultimately used
for /dev/random), e.g. by (semi-)TRNGs like haveged[0],
audio-entropyd[1], Simtec’s Entropy Key[2] or friends... can one spoil
the randomness by that or is this
Hi Filippo.
On Wed, 2008-02-13 at 22:39 +0100, Filippo Zangheri wrote:
> have you conducted further tests? Have you discovered anything?
I actually conducted some tests last week (also with aes-cbc-essiv) but
wasn't able to reproduce the two errors (tested it on the same computer,
with the same
Hi Filippo.
On Wed, 2008-02-13 at 22:39 +0100, Filippo Zangheri wrote:
have you conducted further tests? Have you discovered anything?
I actually conducted some tests last week (also with aes-cbc-essiv) but
wasn't able to reproduce the two errors (tested it on the same computer,
with the same
Hi.
On Wed, 2008-02-06 at 17:36 +0100, Jan Kara wrote:
> I think there's a patch for 2.50 support which is quite recent (2.6.24).
> I plan to merge the support when Sebastian submits it (I'm already in
> contact with him regarding this).
Ah great, so 2.6.25 probably?!
Best wishes,
Chris.
--
To
Hi.
On Wed, 2008-02-06 at 17:36 +0100, Jan Kara wrote:
I think there's a patch for 2.50 support which is quite recent (2.6.24).
I plan to merge the support when Sebastian submits it (I'm already in
contact with him regarding this).
Ah great, so 2.6.25 probably?!
Best wishes,
Chris.
--
To
On Mon, 2008-02-04 at 10:17 +0100, Milan Broz wrote:
> Yes, so if you hit this with 2.6.24 too is very important to sent OOps
> log to identify problem (or link to screen snapshot, digital camera
> snapshot or so).
I did about 5 complete tests today and dozens of mkfs.ext3's but I
wasn't able to
On Mon, 2008-02-04 at 10:17 +0100, Milan Broz wrote:
Yes, so if you hit this with 2.6.24 too is very important to sent OOps
log to identify problem (or link to screen snapshot, digital camera
snapshot or so).
I did about 5 complete tests today and dozens of mkfs.ext3's but I
wasn't able to
Hi Milan Broz
On Sun, 2008-02-03 at 23:06 +0100, Milan Broz wrote:
> Are you sure, that your USB-stick is not faulty ?
I actually tested the stick, too. But I consider problems in the stick
(you mean the key-holding stick, do you?) as highly unlikely.
If the key would be wrong a good crypto
Hi.
I think I've found a bug somewhere in dm-crypt...
First of all the system that I use:
Debian (sid) with kernel 2.26.24 on AMD64 (intel core2 duo), 2GB RAM
For several days now I try to fully encrypt that system (that is, all
partitions are encrypted an I boot from an USB stick)
There are
Hi.
I think I've found a bug somewhere in dm-crypt...
First of all the system that I use:
Debian (sid) with kernel 2.26.24 on AMD64 (intel core2 duo), 2GB RAM
For several days now I try to fully encrypt that system (that is, all
partitions are encrypted an I boot from an USB stick)
There are
Hi Milan Broz
On Sun, 2008-02-03 at 23:06 +0100, Milan Broz wrote:
Are you sure, that your USB-stick is not faulty ?
I actually tested the stick, too. But I consider problems in the stick
(you mean the key-holding stick, do you?) as highly unlikely.
If the key would be wrong a good crypto
Hi everybody.
Does someone know if it's planned (or even in the works) to support
newer versions of the UDF filesystem?
Especially the versions 2.50 and 2.60 would be very interesting for
mounting BluRay discs (and HD DVD)...
I've seen somewhere a patch but that was pretty old and AFAIK not yet
Hi everybody.
Does someone know if it's planned (or even in the works) to support
newer versions of the UDF filesystem?
Especially the versions 2.50 and 2.60 would be very interesting for
mounting BluRay discs (and HD DVD)...
I've seen somewhere a patch but that was pretty old and AFAIK not yet
On Mon, 2008-01-28 at 17:47 -0600, Robert Hancock wrote:
> Nope, I/we are still trying to figure out how to fix this properly..
I see :-)
Uhm is there a bugreport opened, so that I can trace your efforts? Or
would you be so kind to inform me when you have a patch an Linus
accepted it? :-)
btw:
On Mon, 2008-01-28 at 17:38 -0600, Robert Hancock wrote:
> Christoph Anton Mitterer wrote:
> > btw: I'm cross posting this to lkml and debian-user,... hope nobody
> > feels offended :-)
>
> How much RAM is in your machine? There's a known problem with sata_nv
> ADMA wit
Hi everybody.
I've just bought and installed a LG GGW-H20L Blu-Ray burner,...
This is an SATA device, I'm running a 2.6.23.10 kernel (not the Debian
version) on Debian sid (AMD64) and I use the proprietary nvidia drivers
(169.07).
The system is an Dual (!) DualCore AMD Opteron machine.
(Please
Hi everybody.
I've just bought and installed a LG GGW-H20L Blu-Ray burner,...
This is an SATA device, I'm running a 2.6.23.10 kernel (not the Debian
version) on Debian sid (AMD64) and I use the proprietary nvidia drivers
(169.07).
The system is an Dual (!) DualCore AMD Opteron machine.
(Please
On Mon, 2008-01-28 at 17:38 -0600, Robert Hancock wrote:
Christoph Anton Mitterer wrote:
btw: I'm cross posting this to lkml and debian-user,... hope nobody
feels offended :-)
How much RAM is in your machine? There's a known problem with sata_nv
ADMA with ATAPI devices and over 4GB
On Mon, 2008-01-28 at 17:47 -0600, Robert Hancock wrote:
Nope, I/we are still trying to figure out how to fix this properly..
I see :-)
Uhm is there a bugreport opened, so that I can trace your efforts? Or
would you be so kind to inform me when you have a patch an Linus
accepted it? :-)
btw:
Hi.
I'd like to setup a system where all partitions (including the root file
system) are encrypted using dmcrypt.
Of course I need some place where I can boot from, and I intended to use
an USB-stick for that purpose.
Now I think there are (at least) the following two ways of doing this:
1)
Hi.
I'd like to setup a system where all partitions (including the root file
system) are encrypted using dmcrypt.
Of course I need some place where I can boot from, and I intended to use
an USB-stick for that purpose.
Now I think there are (at least) the following two ways of doing this:
1)
Thanks for all your help :-)
Best wishes from Munich,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Hi Alan.
On Fri, 2007-12-14 at 22:24 +, Alan Cox wrote:
> Can you reproduce this without the Nvidia stuff ?
No,.. I'm running for about 2 years now with propreitary nvidia gpu
module,.. but I've never encountered that problem before.
Anyway,... I might have just missed it...
Ah and by the
Hi Tejun.
On Sat, 2007-12-15 at 00:16 +0900, Tejun Heo wrote:
> Do you have log with timestamp? It's difficult to tell what's going on
> without knowing what happened when.
Ah sorry,... I've completely missed that... perhaps those two problems
were not related (at least there's so much time
Hi Tejun.
On Sat, 2007-12-15 at 00:16 +0900, Tejun Heo wrote:
Do you have log with timestamp? It's difficult to tell what's going on
without knowing what happened when.
Ah sorry,... I've completely missed that... perhaps those two problems
were not related (at least there's so much time
Hi Alan.
On Fri, 2007-12-14 at 22:24 +, Alan Cox wrote:
Can you reproduce this without the Nvidia stuff ?
No,.. I'm running for about 2 years now with propreitary nvidia gpu
module,.. but I've never encountered that problem before.
Anyway,... I might have just missed it...
Ah and by the
Thanks for all your help :-)
Best wishes from Munich,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
: enabled, read cache: enabled, doesn't
support DPO or FUA
ata1/sda is my harddisk (at least one of them)
What do does errors mean? Is this probably a hardware failure?
And how can the CD/DVD problem relate to this?
Any ideas?
Thanks and best wishes,
Christoph Anton Mitterer.
total demsg:
us
, read cache: enabled, doesn't
support DPO or FUA
ata1/sda is my harddisk (at least one of them)
What do does errors mean? Is this probably a hardware failure?
And how can the CD/DVD problem relate to this?
Any ideas?
Thanks and best wishes,
Christoph Anton Mitterer.
total demsg:
usb-dib0700
Hi folks.
1) Are there any new developments in this issue? Does someone know if
AMD and Nvidia is still investigating?
2) Steve Langasek from Debian sent me a patch that disables the hw-iommu
per default on Nvidia boards.
I've attached it in the kernel bugzilla and asked for inclusion in the
Hi folks.
1) Are there any new developments in this issue? Does someone know if
AMD and Nvidia is still investigating?
2) Steve Langasek from Debian sent me a patch that disables the hw-iommu
per default on Nvidia boards.
I've attached it in the kernel bugzilla and asked for inclusion in the
Alistair John Strachan wrote:
>> I knew of course about libdvdcss but I've never noticed before that the
>> kernel issues these error messages to the syslog.
>>
> If you've replaced the drive, the decss keys might have changed for inserted
> media (this is especially true if your old drive
Alan wrote:
>> I knew of course about libdvdcss but I've never noticed before that the
>> kernel issues these error messages to the syslog.
>>
> Various bits of random desktop junk poll drives to see what has appeared
> and stick icons on desktops. Some of them do stuff that produces messages
Alan wrote:
I knew of course about libdvdcss but I've never noticed before that the
kernel issues these error messages to the syslog.
Various bits of random desktop junk poll drives to see what has appeared
and stick icons on desktops. Some of them do stuff that produces messages
like
Alistair John Strachan wrote:
I knew of course about libdvdcss but I've never noticed before that the
kernel issues these error messages to the syslog.
If you've replaced the drive, the decss keys might have changed for inserted
media (this is especially true if your old drive had a
Alan wrote:
>> kernel: Error: Illegal request -- (Sense key=0x05)
>> kernel: Read of scrambled sector without authentication -- (asc=0x6f,
>> ascq=0x03)
>>
>
> The disc is using digital rights management. If you are in a country that
> permits it you can use a dvd reader library with
Hi.
I'm using a kernel 2.6.18.1 with a Plextor PX-769A CD/DVD drive (using
the old IDE drivers)... The drive itself is brand-new. The firmware
version is 1.06 (which is the most recent).
There are to issues I experience.
1) On some (but not all) DVD-Videos I get the following messages:
kernel:
Hi.
I'm using a kernel 2.6.18.1 with a Plextor PX-769A CD/DVD drive (using
the old IDE drivers)... The drive itself is brand-new. The firmware
version is 1.06 (which is the most recent).
There are to issues I experience.
1) On some (but not all) DVD-Videos I get the following messages:
kernel:
Alan wrote:
kernel: Error: Illegal request -- (Sense key=0x05)
kernel: Read of scrambled sector without authentication -- (asc=0x6f,
ascq=0x03)
The disc is using digital rights management. If you are in a country that
permits it you can use a dvd reader library with decss support,
Erik Andersen wrote:
> I just tried again and while using iommu=soft does avoid the
> corruption problem, as with previous kernels with 2.6.20-rc5
> using iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
> I still have to disable memhole and lose 1 GB. :-(
Please add this to the
joachim wrote:
> Not only has it only been on Nvidia chipsets but we have only seen
> reports on the Nvidia CK804 SATA controller. Please write in or add
> yourself to the bugzilla entry [1] and tell us which hardware you have
> if you get 4kB pagesize corruption and it goes away with
joachim wrote:
Not only has it only been on Nvidia chipsets but we have only seen
reports on the Nvidia CK804 SATA controller. Please write in or add
yourself to the bugzilla entry [1] and tell us which hardware you have
if you get 4kB pagesize corruption and it goes away with iommu=soft.
How
Erik Andersen wrote:
I just tried again and while using iommu=soft does avoid the
corruption problem, as with previous kernels with 2.6.20-rc5
using iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
I still have to disable memhole and lose 1 GB. :-(
Please add this to the bugreport
Andi Kleen wrote:
> AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
> although there were similar problems on VIA in the past too.
> Unless a good workaround comes around soon I'll probably default
> to iommu=soft on Nvidia.
I've just read the posts about AMDs and NVIDIAs
Chris Wedgwood wrote:
> I'd like to here from Andi how he feels about this? It seems like a
> somewhat drastic solution in some ways given a lot of hardware doesn't
> seem to be affected (or maybe in those cases it's just really hard to
> hit, I don't know).
>
Yes this might be true,.. those
Arkadiusz Miskiewicz wrote:
> FYI it seems that I was also hit by this bug with qlogic fc card + adaptec
> taro raid controller on Thunder K8SRE S2891 mainboard with nvidia chipset on
> it.
>
>
Chris Wedgwood wrote:
> right now i'm thinking if we can't figure out which cpu/bios
> combinations are safe we might almost be better off doing iommu=soft
> for *all* k8 stuff except for those that are whitelisted; though this
> seems extremely drastic
>
I agree,... it seems drastic, but this
Robert Hancock wrote:
>> What is that GART thing exactly? Is this the hardware IOMMU? I've always
>> thought GART was something graphics card related,.. but if so,.. how
>> could this solve our problem (that seems to occur mainly on harddisks)?
>>
> The GART built into the Athlon 64/Opteron
Robert Hancock wrote:
What is that GART thing exactly? Is this the hardware IOMMU? I've always
thought GART was something graphics card related,.. but if so,.. how
could this solve our problem (that seems to occur mainly on harddisks)?
The GART built into the Athlon 64/Opteron CPUs is
Chris Wedgwood wrote:
right now i'm thinking if we can't figure out which cpu/bios
combinations are safe we might almost be better off doing iommu=soft
for *all* k8 stuff except for those that are whitelisted; though this
seems extremely drastic
I agree,... it seems drastic, but this is
Arkadiusz Miskiewicz wrote:
FYI it seems that I was also hit by this bug with qlogic fc card + adaptec
taro raid controller on Thunder K8SRE S2891 mainboard with nvidia chipset on
it.
Chris Wedgwood wrote:
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem to be affected (or maybe in those cases it's just really hard to
hit, I don't know).
Yes this might be true,.. those who
Andi Kleen wrote:
AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
although there were similar problems on VIA in the past too.
Unless a good workaround comes around soon I'll probably default
to iommu=soft on Nvidia.
I've just read the posts about AMDs and NVIDIAs effort
Sorry, as always I've forgot some things... *g*
Robert Hancock wrote:
> If this is related to some problem with using the GART IOMMU with memory
> hole remapping enabled
What is that GART thing exactly? Is this the hardware IOMMU? I've always
thought GART was something graphics card related,..
Hi everybody.
Sorry again for my late reply...
Robert gave us the following interesting information some days ago:
Robert Hancock wrote:
> If this is related to some problem with using the GART IOMMU with memory
> hole remapping enabled, then 2.6.20-rc kernels may avoid this problem on
>
Hi.
Some days ago I received the following message from "Sunny Days". I
think he did not send it lkml so I forward it now:
Sunny Days wrote:
> hello,
>
> i have done some extensive testing on this.
>
> various opterons, always single socket
> various dimms 1 and 2gb modules
> and hitachi+seagate
Hi.
Some days ago I received the following message from Sunny Days. I
think he did not send it lkml so I forward it now:
Sunny Days wrote:
hello,
i have done some extensive testing on this.
various opterons, always single socket
various dimms 1 and 2gb modules
and hitachi+seagate disks
Hi everybody.
Sorry again for my late reply...
Robert gave us the following interesting information some days ago:
Robert Hancock wrote:
If this is related to some problem with using the GART IOMMU with memory
hole remapping enabled, then 2.6.20-rc kernels may avoid this problem on
nForce4
Sorry, as always I've forgot some things... *g*
Robert Hancock wrote:
If this is related to some problem with using the GART IOMMU with memory
hole remapping enabled
What is that GART thing exactly? Is this the hardware IOMMU? I've always
thought GART was something graphics card related,..
Hi.
Just for you information: I've put the issue into the kernel.org bugzilla.
http://bugzilla.kernel.org/show_bug.cgi?id=7768
Chris.
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard
Hi.
Just for you information: I've put the issue into the kernel.org bugzilla.
http://bugzilla.kernel.org/show_bug.cgi?id=7768
Chris.
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard
spent
> considerable time attempting to reproduce this problem on one of our
> reference motherboards without success. If you could ship a system
> which reliably reproduces the problem, I'd be happy to investigate further.
>
> Thanks,
> Lonni J Friedman
> NVIDIA Corporation
>
&g
considerable time attempting to reproduce this problem on one of our
reference motherboards without success. If you could ship a system
which reliably reproduces the problem, I'd be happy to investigate further.
Thanks,
Lonni J Friedman
NVIDIA Corporation
Christoph Anton Mitterer wrote:
Hi
John A Chaves wrote:
> I didn't need to run a specific test for this. The normal workload of the
> machine approximates a continuous selftest for almost the last year.
>
> Large files (4-12GB is typical) are being continuously packed and unpacked
> with gzip and bzip2. Statistical analysis of
Hi my friends
It became a little bit silent about this issue... any new ideas or results?
Karsten Weiss wrote:
> BTW: Did someone already open an official bug at
> http://bugzilla.kernel.org ?
Karsten, did you already file a bug?
I told the whole issue to the Debian people which are
Hi my friends
It became a little bit silent about this issue... any new ideas or results?
Karsten Weiss wrote:
BTW: Did someone already open an official bug at
http://bugzilla.kernel.org ?
Karsten, did you already file a bug?
I told the whole issue to the Debian people which are about
John A Chaves wrote:
I didn't need to run a specific test for this. The normal workload of the
machine approximates a continuous selftest for almost the last year.
Large files (4-12GB is typical) are being continuously packed and unpacked
with gzip and bzip2. Statistical analysis of the
Muli Ben-Yehuda wrote:
>> 4)
>> And does someone know if the nforce/opteron iommu requires IBM Calgary
>> IOMMU support?
>>
> It doesn't, Calgary isn't found in machine with Opteron CPUs or NForce
> chipsets (AFAIK). However, compiling Calgary in should make no
> difference, as we detect in
Muli Ben-Yehuda wrote:
4)
And does someone know if the nforce/opteron iommu requires IBM Calgary
IOMMU support?
It doesn't, Calgary isn't found in machine with Opteron CPUs or NForce
chipsets (AFAIK). However, compiling Calgary in should make no
difference, as we detect in run-time
Hi.
I've just looked for some kernel config options that might relate to our
issue:
1)
Old style AMD Opteron NUMA detection (CONFIG_K8_NUMA)
Enable K8 NUMA node topology detection. You should say Y here if you
have a multi processor AMD K8 system. This uses an old method to read
the NUMA
Lennart Sorensen wrote:
> I upgrade my plextor firmware using linux. pxupdate for most devices,
> and pxfw for new drivers (like the PX760). Works perfectly for me. It
> is one of the reasons I buy plextors.
Yes I know about it,.. although never tested it,... anyway the main
reason for Windows
Erik Andersen wrote:
> I just realized that booting with "iommu=soft" makes my pcHDTV
> HD5500 DVB cards not work. Time to go back to disabling the
> memhole and losing 1 GB. :-(
Crazy,...
I have a Hauppauge Nova-T 500 DualDVB-T card,... I'll check it later if
I have the same problem and will
Chris Wedgwood wrote:
>> Did anyone made any test under Windows? I cannot set there
>> iommu=soft, can I?
>>
> Windows never uses the hardware iommu, so it's always doing the
> equivalent on iommu=soft
>
That would mean that I'm not able to reproduce the issue unter windows,
right?
Does
Karsten Weiss wrote:
> "Memory hole mapping" was set to "hardware". With "disabled" we only
> see 3 of our 4 GB memory.
>
That sounds reasonable,... I even only see 2,5 GB,.. as my memhole takes
1536 MB (don't ask me which PCI device needs that much address space ;) )
begin:vcard
fn:Mitterer,
Karsten Weiss wrote:
> Of course, the big question "Why does the hardware iommu *not*
> work on those machines?" still remains.
>
I'm going to check AMDs errata docs these days,.. perhaps I find
something that relates. But I'd ask you to do the same as I don't
consider myself as an expert in
Ah and I forgot,...
Did anyone made any test under Windows? I cannot set there iommu=soft,
can I?
Chris.
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard
1 - 100 of 124 matches
Mail list logo
