Re: chk drive for errors?

On Sat, 21 Jul 2007, imotgm wrote:-

On Sun, 22 Jul 2007 01:22:48 +0100, David Bolt wrote:

It was fun while it lasted :-)

I'm sure we'll do it again, sometime. ;-)

And why not. There's always news fish to catch :-)

That sounds a little like sour grapes.

I thought so. Last thing they (Mandriva) bitched about was how TexStar
used the Mandriva sources, but didn't give the rebuilt packages back to
Mandriva.

Erm...

WTF? "You build bad packages, why don't you give them back to us?" What's
wrong with this picture?

Whoever said it was playing the idiot? And was stopping them from
building their own packages, using the TexStar source packages as the
basis?

I'll have to fire up a couple of VMs and do a comparison. I know that
Mandriva 2007 wasn't too bad when I tried it, although it "still didn't
feel quite right." A worse thing, for me at the time, was I didn't like
the package management. I wanted a quick and easy method of installing
the development packages so I could build for multiple distros, and it
didn't seem to be an easy thing with their package management system. I
suppose I should have stuck with it a little longer and I'd have figured
it out.

If you have a partition to spare, I'd suggest a full installation,

It's a VM. It'll have a virtual machine all to itself :-)

if
you're interested in seeing how they set up Beryl.

Not particularly. I much prefer a plain(ish) desktop, which is strange
since I use KDE.

You can just run it
from the live CD, but I don't think it will work on a VM.

It should do. Even Toms Root Boot disc works, as does the Live CD for
knoppix :-)

Maybe the newest
VMWare might, as I hear it does 3D now.

I'm running VMware Server 1.0.3 and Parallels and I know Parallels
doesn't do 3D. I don't think the version of VMware I'm using does
either.

And I guess you need the pata_it821x driver. Now, do you really need to
eliminate every pata_* module, or just some of them?

No, I need the older it821x, which is what I have. The pata_it821x makes
the IDE drives appear as SCSI drives, the same as SATA drives, and limits
the number of partitions to 15.

That's an old limit that SCSI had. Moving SATA, and now IDE, under SCSI
means everything gets that 15 partition limit. LVM is one way round that
limit.

I have some IDE/PATA drives with 18
partitions, so that's a no go from the start, even if the drivers worked
properly.

IIRC, there was discussion on the Factory list about this when the swap
was made, and the suggestion was to make the kernel use the older
modules. IIRC, there was mention of patching libata[0] so it would
support more than 15 partitions. I don't recall exactly what the
conclusion was, or whether there was actually going to be a patch, but
I'm sure a search of the archive will show it up.

With drive size going up constantly, I have a hard time grasping
why it was OK to allow drives, less than 1GB in size, to be able to have
63 partitions, but a new 1TB drive should be limited to 15.

I think the idea is that, nowadays, people would be using LVM and
putting (almost) all the various partitions inside a logical volume.

The logic here
escapes me. Also hdparm automatically gets broken in the process, and
sdparm doesn't work right with PATA drives either.

You did tell it to use the ATA transport ( -t ATA ) ?

Because the drives had different physical properties, unix always treated
IDE, and SCSI, as separate entities. With SATA mostly replacing SCSI
drives, they were treated by Linux as SCSI, to separate them from PATA, so
you'd know which was which, even though the are in fact, still IDE drives,
with a serial interface.

Have you looked at the ATA commands? AFAIK they're almost a subset of
SCSI.

Now the kernel boys, claiming the older IDE code
is getting krufty, decided all drives should be brought under libata, and
treated as SCSI, so they only have one drive source tree to worry about.

I can understand that. Less stuff to maintain, and less duplication of
efforts.

My take is, that's just lazy. If the code is krufty, fix it, don't break
the functionality of the drives, for coder convenience. Same goes for USB.

In most common situations it doesn't the functionality. It's only when
you get someone creating a larger than normal number of partitions that
there's a problem.

Windows does not treat USB as SCSI, but as an entity with it's own
identity.

That's probably because the Windows developers don't like the idea of
talking to each other and sharing ideas. On top of that, it's all been
bolted on, with additional bolt-ons with each new release.

Most of the problems with USB on Linux come from insisting on
using the SCSI tree to control USB, and trying to work within the confines
of that format.

Well, so far, I've not had a problem with USB drives.

If you look, you'll probably find quite a few other things listed as
"Experimental" or "Very Experimental" that, despite the labels, are
actually quite stable.

These aren't. I figure, one should be presented with an installation
kernel that is pretty much plain jane, with solid drivers, for most
computers, and a choice to have another, experimantal kernel, that has all
the latest whiz bang stuff for those who can't live with any hardware not
produced in the last week.

Well, I can honestly say I'm not in that group. Almost all my hardware
is over a year old. The only things that aren't are a single replacement
NIC, for one that went duff, and a couple of hard drives.

I mostly choose my hardware very carefully, so
I know it's fully supported in Linux. When my two year old, fully
supported from day one, hardware suddenly becomes unsupported, because
someone had the bright idea that in order to support the newest, latest
and greatest, we should break that which has performed flawlessly,
for years, before the change, I get a bit miffed.

I can understand that.

I was going to ask for the bug number, in a "I can't be a***ed to do the
search" sort of "me, me, me" manner, but decided it'd be quicker if I
searched the mails from the mailing list instead.

I meant to include it, and only noticed it's absence after i checked the
post. Had you not found it, I would have included it in this post. ;-)

I'm on the bugzilla mailing list and just did a search for your nick.
It's not like it's a common nick :-)

Have you tried the vanilla kernel.org sources and used the SUSE .config?

Not actually, as I'm still trying to work with the bugzilla boys, so want
as much of the SUSE kernel as possible, patches and fixes included, just
not the broken parts.

I'd start with the vanilla kernel and see if that works. If it does,
it's a SUSE patch that's at fault. If it doesn't, you need to be talking
to the kernel guys.

Extract the sources for both versions and do a diff on both of the
trees. See if you can find any changes to the modules.

That's the plan, Stan. However, the .configs could be exactly the same,
while the patch code changes how it compiles, and I don't read code any
better than I write it.

:-)

I did try to hide it but, yes, I certainly am glad it's you and not me.
:-)

I knew it. That evil glint, in the eye of your smiley, gave it away.

I'll wear mirrored glasses next time.

Naughty, naughty David. ;)

You been talking to my wife? She keeps saying that to me as well ;-)


[0] That speel chucker of mine still wants to change that to labia. I'm
sure it's trying to shift my train of thought :-)

Regards,
David Bolt

--
Member of Team Acorn checking nodes at 100 Mnodes/s: www.distributed.net
RISC OS 3.11 | SUSE 10.0 32bit | SUSE 10.1 32bit | openSUSE 10.2 32bit
RISC OS 3.6 | SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit
TOS 4.02 | SUSE 9.3 32bit | | openSUSE 10.3a6 32bit
.

Relevant Pages

  • [PATCH 18-rc2] Fix typos in /Documentation : N-P
    ... Again, if you're not gonna do synchronization with disk drives (dang, ... -the kernel. ... There are two options specific to PSX driver portion. ... The driver uses the settings from the EEPROM set in the SCSI BIOS ...
    (Linux-Kernel)
  • Re: Weird kernel errors
    ... This may be related to the kernel error message: ... >> The second is that my hard disks won't accept DMA enabling, ... No DMA on any of the drives. ... > allotted partitions if they aren't "right"). ...
    (uk.comp.os.linux)
  • Re: [kde] Starting kde
    ... is detected by the scsi card but not by the kernel. ... The scsirastools don't seem to need the drives to ... if they had reported the problem and carried on into kde. ...
    (KDE)
  • Re: Where did you get them there devices ?
    ... point me to the mechanism or kernel ... controller, and the address of the controller. ... SCSI controllers, the order of the controllers depended on how the ... Drives on a SCSI controller have an address, ...
    (Fedora)
  • Re: Plextor PX-716sa DVD-burner how to make it work under SuSE 9.2?
    ... >> kernel any way) with SATA, so I thought I would be safe. ... >mode, the HDs are presented as SCSI ... ATA drives, but I am not really any sort of expert, so I may be just ...
    (comp.os.linux.hardware)