On 27/12/2012, at 13:44, Peter Jeremy pe...@rulingia.com wrote:
I've only caught it hanging forever once. It only takes a few
milliseconds to cause incoming data to be lost,
I'm not sure what you mean by this. FreeBSD is not a real-time
operating system and so offers no guarantees on how
If the driver is doing something daft like DELAY(x) in a fast
interrupt handler which would lead to that behaviour, it should be
fixed.
If it's doing a DELAY(x) in a critical section, it shuld be fixed.
They are doing *something* that completely locks out everything else.
It is always a
Hm, can you come up with a reproducable scenario where this happening?
A lot of times the issues with disk drivers being upset is due to
bad or incorrectly seated SATA cables.
We're willing to help you out if you're willing to delve into the
driver. Just ask questions about how it works and
On 2012-Dec-25 21:51:14 -0500, Dieter BSD dieter...@engineer.com wrote:
ata(4) completely hung the system for 19 minutes (at which point
I manually intervened, see the PR), probably an infinite loop.
http://www.freebsd.org/cgi/query-pr.cgi?pr=170675
Which contains no useful information. You've
Which device drivers? We can't fix problems we don't know about.
ata(4) completely hung the system for 19 minutes (at which point
I manually intervened, see the PR), probably an infinite loop.
http://www.freebsd.org/cgi/query-pr.cgi?pr=170675
Siis(4) and ahci(4) have also caused data loss,
Hi,
If the driver is doing something daft like DELAY(x) in a fast
interrupt handler which would lead to that behaviour, it should be
fixed.
If it's doing a DELAY(x) in a critical section, it shuld be fixed.
Otherwise, a DELAY(x) in a driver only chews CPU; the scheduler can
preempt that. I
Am 12.12.2012 23:26, schrieb Wojciech Puchar:
The cause of the low write performance is the disabled write cache.
Enabling the write cache is unsafe on SATA drives (with or without
NCQ), since they do not make any guarantees that nearby data is not
lost if power fails during a disk write. It
There is no technical reason that SATA drives are less reliable with
regard to hardware (bit density, BER, ...) and firmware (less strict
conformance testing compared to SAS drives), but there are market
forces that have this effect.
The only sentence i could agree.
But actually it is mostly
people are often trying to squeeze out that last drop of performance,
Linux is certainly a steaming pile of crap. BSD is orders of magnitude
better, but hey, that doesn't take much.
just pray FreeBSD will not incorporate too much modern technologies if
you know what i mean.
But don't
2) Although I don't know a lot about boards, it is my understanding that
ASUS makes pretty good ones, and they have always worked for me (and the
firmware is typically quite good).
maybe it's strange for for a long time i NEVER really succeeded making
stable configuration from popular parts.
what's a point of not using ahci(4)?
On Sat, 8 Dec 2012, Adrian Chadd wrote:
Hi,
Yes. atacam supports NCQ.
The older IDE/ATA code doesn't support NCQ. The CAM ATA code (ie,
atacam) supports it if the drive supports it.
So, the FreeBSD doesn't do NCQ point is incorrect.
If you don't believe
B. Use GPT, which does not have the CHS baggage. It is easier and more
bsd labels doesn't have too
versatile. My systems with GPT disks don't complain about track
alignment. Or maybe that's ahci(4)'s doing.
___
freebsd-hackers@freebsd.org
So clock rate is the only thing that matters in your world?
Yea, pretty much.
operations per second do matter. compared to latest x86 hardware alpha
lose even at the same clock speed.
___
freebsd-hackers@freebsd.org mailing list
Am 11.12.2012 22:40, schrieb Adrian Chadd:
I'm not seeing:
* any references to driver code that exhibits that very broken behaviour;
* any patches from you to implement NCQ on your nforce chipset;
* any offer of incentive to any developer to add that support.
Now, (1) is definitely
The cause of the low write performance is the disabled write cache.
Enabling the write cache is unsafe on SATA drives (with or without
NCQ), since they do not make any guarantees that nearby data is not
lost if power fails during a disk write. It never happened to me,
but there is a reason that
Ronald writes:
the last Alpha to be produced was shipped way back in 2004... eight years
ago... with a top speed of 1.3 GHz I now have a cheap little media player
thingy sitting on my desk, and _each_ of its two cores runs faster than tha\
t.
In short, Alphas hardly constitute high-end
I'm not seeing:
* any references to driver code that exhibits that very broken behaviour;
* any patches from you to implement NCQ on your nforce chipset;
* any offer of incentive to any developer to add that support.
Now, (1) is definitely worrying but as you've not provided any actual
On 2012-Dec-11 15:43:21 -0500, Dieter BSD dieter...@engineer.com wrote:
I care about data integrity, so things like ECC are on my must-have list.
Well, that's supported by all server CPUs (AMD Opteron, Intel Itanium,
Intel Xeon, Oracle/Sun SPARC) and some desktop CPUs (most AMD x86 chips).
A
Ronald writes:
the last Alpha to be produced was shipped way back in 2004... eight years
ago... with a top speed of 1.3 GHz. I now have a cheap little media player
thingy sitting on my desk, and _each_ of its two cores runs faster than that.
In short, Alphas hardly constitute high-end
Right, so the bug here is why isn't atacam attaching to the nforce4
ultra chipset.
So this has changed from FreeBSD doesn't do NCQ to FreeBSD doesn't
do NCQ on my particular desktop-aimed motherboard chipset. They're
slightly different in scope, wouldn't you agree?
Please file a PR and see if
Right, so the bug here is why isn't atacam attaching to the nforce4
ultra chipset.
So this has changed from FreeBSD doesn't do NCQ to FreeBSD doesn't
do NCQ on my particular desktop-aimed motherboard chipset. They're
slightly different in scope, wouldn't you agree?
Please file a PR and see if
On Sun, 9 Dec 2012, Dieter BSD wrote:
B. Use GPT, which does not have the CHS baggage. It is easier and more
versatile. My systems with GPT disks don't complain about track
alignment. Or maybe that's ahci(4)'s doing.
I never found a way to boot from different partitions, much less
In message 20121209091305.238...@gmx.com,
Dieter BSD dieter...@engineer.com wrote:
Ronald writes:
the last Alpha to be produced was shipped way back in 2004... eight years
ago... with a top speed of 1.3 GHz. Â I now have a cheap little media player
thingy sitting on my desk, and _each_ of
.. the problem with Alpha is that there wasn't anyone who wanted to
support it any longer.
If someone wanted to stand up and resurrect it, support it, etc; I
doubt the FreeBSD project would complain.
The same thing is happening with ia64. Marcel still cares and he still
does a lot of ia64 heavy
[ lack of SATA NCQ support for nforce4-ultra ]
Adrian writes:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e2e031eb09760c36099ac127eeb175e06d257aef
which is:
The mcp61 has bug with ncq.
- { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA), SWNCQ },
- {
[ lack of SATA NCQ support for nforce4-ultra ]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e2e031eb09760c36099ac127eeb175e06d257aef
which is:
The mcp61 has bug with ncq.
- { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA), SWNCQ },
- {
Ronald writes:
This probably wouldn't be such a big deal if we were just talking about
Linux. But FreeBSD has always prided itself on being a serious OS for
serious people with serious work to do... like major server farms and
such. In the context of high-end applications on high-end
In message 20121209014547.238...@gmx.com,
Dieter BSD dieter...@engineer.com wrote:
But don't brag about high-end hardware. Â But FreeBSD has dropped support
for even semi-high-end hardware (DEC Alpha). So I'm stuck running it on
AMD64. Nothing against AMD, they did what they could to try and
On Sat, 08 Dec 2012 19:52:34 -0800
Ronald F. Guilmette r...@tristatelogic.com wrote:
analysis skipped.
As regards to the Native Command Queuing all I can say is Crap!
I wasn't aware...until now... that FreeBSD did not support that. That
really is a rather entirely serious issue. But I
On 8 December 2012 23:04, Alexander Kabaev kab...@gmail.com wrote:
On Sat, 08 Dec 2012 19:52:34 -0800
Ronald F. Guilmette r...@tristatelogic.com wrote:
analysis skipped.
As regards to the Native Command Queuing all I can say is Crap!
I wasn't aware...until now... that FreeBSD did not
Hi,
Yes. atacam supports NCQ.
The older IDE/ATA code doesn't support NCQ. The CAM ATA code (ie,
atacam) supports it if the drive supports it.
So, the FreeBSD doesn't do NCQ point is incorrect.
If you don't believe me - look in sys/cam/ata/ata_da.c, look for ata_ncq_cmd().
Adrian
On 8 December 2012 23:19, Adrian Chadd adr...@freebsd.org wrote:
Hi,
Yes. atacam supports NCQ.
The older IDE/ATA code doesn't support NCQ. The CAM ATA code (ie,
atacam) supports it if the drive supports it.
So, the FreeBSD doesn't do NCQ point is incorrect.
If you don't believe me - look
On Sat, 8 Dec 2012, Dieter BSD wrote:
Having a 4KiB misalignment is nothing compared with not having NCQ
support.
...
Speaking of alignment, I still get partition 1 does not end on a
track boundary messages. FreeBSD has no clue where the track boundaries
are and neither do I. Disks have used
33 matches
Mail list logo
