Hi - I'm an experienced Linux user. I'm trying to setup a machine and
having loads of problems. I've tried Debian, Mandriva, Gentoo and more
- seem to be running into the same proble.

None of the install CD's will boot without me specifying the ide=nodma
option, I'm using a 2.5" Samsung drive, 40GB. Now - when I try to run
fdisk, I can partition the drive as I see fit and select 'w' to write
the table. Fdisk then exits, when I run it again, I still have the same
number of partitions, but the type has been changed to NTFS Volume Set
and the sector starts overlap.

I have no idea how to proceed, not sure if this is a DMA problem, a
bios problem or a driver problem. Thoughts?

On Fri, 30 Sep 2005 21:48:33 -0700, matthewt wrote:

> Hi - I'm an experienced Linux user. I'm trying to setup a machine and
> having loads of problems. I've tried Debian, Mandriva, Gentoo and more -
> seem to be running into the same proble.
>
> None of the install CD's will boot without me specifying the ide=nodma
> option, I'm using a 2.5" Samsung drive, 40GB. Now - when I try to run
> fdisk, I can partition the drive as I see fit and select 'w' to write
> the table. Fdisk then exits, when I run it again, I still have the same
> number of partitions, but the type has been changed to NTFS Volume Set
> and the sector starts overlap.
>
> I have no idea how to proceed, not sure if this is a DMA problem, a bios
> problem or a driver problem. Thoughts?

I don't think this is a BIOS problem. Certainly not a DMA problem. fdisk
doesn't use filesystem drivers. fdisk is a pretty low-level utility, the
number of places where things can go wrong in limited.

Just to see if you can get things to work, after setting up the partitions
in fdisk, and before quitting, press x, d to see the raw partition table.
Copy down the values. Exit fdisk. Use hexdump to view the partition table.
If its not what you expect, use hexedit to change the setting to the
desired values. Run hexdump again to ensure the settings are OK. Run fdisk
to see what it shows.

I will try that. I'd also like to add it's not a hardware or cable
proble, since I have 2 identical drives and 2 identical machines and am
getting the same error...

<matthewt@gmail.com> wrote in message
news:1128149160.672739.232890@g14g2000cwa.googlegr oups.com...
>I will try that. I'd also like to add it's not a hardware or cable
> proble, since I have 2 identical drives and 2 identical machines and am
> getting the same error...

This nastiness sounds BIOS related, to me. What are these "identical
machines"? Really old, so old that they may hve various antique 1024
cylinder BIOS limitations and won't properly handle drives of more than 8
Gig size? What partition layout are you trying to use, a single large
partition with maybe some swap space and a small /boot partition? Or dozens
of LVM partitions, or what? Or maybe you have some bleeding edge SATA
controller made by a vendor who refuses to ever answer the tech support
phone with a real human, like Promise?

It's a small appliace type machine running a Via processor. I have
built several of these w/ 20gig drives - no problems...

On Sun, 02 Oct 2005 02:10:51 +0200, <matthewt@gmail.com> wrote:

> It's a small appliace type machine running a Via processor. I have
> built several of these w/ 20gig drives - no problems...

Since you fail to quote the earlier messages I have to gather the
information from three messages.

Ummm...

You have built several machines of the same type,
o Appliance type
o running a Via processor
o with 20 Gb drives, except two have 40 Gb drives instead

The 40 Gb drives are Samsung 2.5".

The two with 40 Gb behave differently.

You cannot boot those two from CD without setting ide=nodma on the
kernel boot command line, do I get it right? (What are the symptoms
when you don't supply ide=nodma? Can we infer that the disk interface
is traditional IDE?

You use fdisk => meaning you have booted some kernel and are
running fdisk under that kernel. With ide=nodma.

You set up one or more partitions, then hit "w" and return.

Fdisk queries the kernel about the number of bytes per sector
and the total capacity in bytes of the disk, and uses llseek()
and read() to read the second and the last sector of the disk.

In my test case, the disk had no extended partition.

Fdisk uses llseek() and write() to write a 512-byte block to
the start of the disk, calls sync(), waits for two seconds,
calls an ioctl() to make the kernel reread the partition table,
and repeats sync()-sleep()-ioctl(), sleeps for another four seconds,
and exits.

If you changed any logical partitions fdisk probably called llseek
to reach the proper sector, read the sector, modified the memory
copy of the sector, called llseek() again to access the same sector
again, then wrote the modified sector back. Repeat for each partition
modified. Or perhaps for all logical partitions.

Now you restart fdisk, but the partition data do not correspond to
the data written.

The exact nature of the differences between written and subsequently
read is perhaps not so important as noting that the contenst of one
or more sectors have changed.

Just for the record, the number of partitions is the same...
as before? as written? I guess the disks had empty partition
tables when you started, so you mean the same as written.
Some partition(s) have changed type to ntfs (where ext3?)
Partition start (first sector) overlap ... overlap what? The end
of previous partition? If the disks had empty partition
tables when you started, it means the sectors have been written.
Number of partitions read is the same as written.


We have some options.

Did the write hit the disk? Or did the kernel keep it in
its buffercache?

Block device reads and writes go through the buffercache.
Sync should force out everything. Is there any possibility that
something delayed the write so much that the call to reread the
partition table clobbered unwritten buffercache blocks with the
old data from the disk?

I don't know if sync() waits until the data are actually safely on
the platter. I *believe* it does.

Do some hardware conditions corrupt the data on the way to the disk?
Do some hardware conditions corrupt the data being read from the disk?

Are there kernel bugs that give timing errors or other corrupting
errors when using ide=nodma? Are there memory errors?

Could there be electrical problems, with the disks drawing too much
current and making the power drop below what the ram likes?
Do you have any means of observing that?

You probably have mostly readonly filesystems as long as you
are running from a CD. But /dev is a tmpfs, so if you have some
memory to spare, you can hold short files there. Can you
do

dd bs=512 count=1 if=/dev/hda (or whatever) of=/dev/mbr-before

then run fdisk, and from the advanced menu hexdump the partition
table, then partition as it should be, hexdump again, save the
dumps to /dev/something, and finally repeat the dd command, but
with of=/dev/mbr-after. Then od -t x1 /dev/mbr-before and
see if there are any pattern in the differences. I cannot imagine
you can do much more from software except debug the kernel.

The rest would be fairly lowlevel properties of the disks and the
chips on the appliance.

-Enrique
of=/

To recap - having problems w/ a small appliance type machine running a
Via processor and Epia motherboard. I have used these before w/ 20gig
drives, no problem. I have 2 more and 2 Samsung 40gb drives and am now
having problems. No distros would boot w/out ide=nodma. Then when I try
to partition the drive using fdisk, it appears to work, but does not
actually "save" the table after I exit.

Some updates - I can get the system to boot using a Knoppix dervied
Live CD w/out specifying ide=nodma. Now when I run fdisk and partition
the drives - same problem. Some people suggested I jot down the
partition table using fdisk, then use hexdump to compare after I exit.

I did this (hexdump -C -n 1024 /dev/hdc) and the table is not the same.
It's almost as if the drive won't write when I exit. The other odd
thing, if I make 3 partitions - say a 32M /boot, a 512M swap and the
remainder dedicated to / and save, when I exit and look again it
appears as if the hdc2 and hdc3 overlap sectors. Something is wrong
with how the machine is reading the disk...

Any ideas here? Bios seems to recognize the drive using LBA or auto. I
have also tried manually setting the cylinders, heads and sectors using
fdisk.

On 3 Oct 2005 11:42:30 -0700, matthewt@gmail.com
<matthewt@gmail.com> wrote:
> To recap - having problems w/ a small appliance type machine running a
> Via processor and Epia motherboard. I have used these before w/ 20gig
> drives, no problem. I have 2 more and 2 Samsung 40gb drives and am now
> having problems. No distros would boot w/out ide=nodma. Then when I try
> to partition the drive using fdisk, it appears to work, but does not
> actually "save" the table after I exit.
>
Have you checked the BIOS to see if there is a "virus protection"
option? If there is, you should turn it off.


--
Neutrinos have bad breadth.