Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fully sane on Alpha - file systems

2001-02-15 Thread Michal Jaegermann

On Thu, Feb 15, 2001 at 03:15:01PM -0500, John Jasen wrote:
> 
> I retried the mysticism and incantations (d -l 801feac d) at the srm
> prompt, and the machine locked on fsck, under kernel 2.4.1-ac13.

Like I wrote - I did not get to locks on fsck but then stuff was weird
and if I would press sufficiently long maybe I would.  I still had some
use for my file systems so I did not try hard enough.  Maybe we need
black hens on the top of the magic quoted above?

> I don't care about X on this system, all that much, honestly.

"Technicolor" thingy seems to be side effect of your particular
graphics card, no?

  Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fully sane on Alpha - file systems

2001-02-15 Thread Michal Jaegermann

On Thu, Feb 15, 2001 at 12:49:29PM -0500, John Jasen wrote:
> 
> Well, the situation is improving, I suppose ...
> 
> Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
> the system to go technicolor and lock up.

On UP1100 which I have here somehow this looks a bit different _after_
I put on it the latest SRM and used this "magic incantation" from
Hyung Min SEO ('d -l 801feac d' at SRM prompt to modify firmware).
I copied from disk to disk directory tries with some 150 MB of data
in these and no ill effects.

OTOH things are still wobbly.  This shows up in this that trying to
run e2fsck on a dirty file system while booting one 2.4.1 is likely
to come up with all kind of errors in a file sytstem requiring manual
interactions.  If one breaks this process and repeats an exercise
on the same file system, but booting this time 2.2.18, then things
check out without any incidents.  Once clean file systems can be
used with 2.4.1 again and no problems are reported.

I really do not see any kernel problems with 2.2 series kernels and IDE
patches.

> Now, under 2.4.1-ac13, at about 11000 blocks, it goes technicolor, but
> doesn't lock up until somewhere between 13000 and 2.

I got various lockups but no "technicolor" on any occasion.  Recently
I even got a picture with X and G450 Matrox card although one can
be very careful not to look at it a wrong angle or a power button will
be the only way out.

  Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: 2.4.1 not fully sane on Alpha - file systems

2001-02-01 Thread Michal Jaegermann

To follow my own message about lockups on UP1100.  This time I tried
to boot 2.4.1-ac1.  Results are really the same but this time
an attempt to copy kernel source from a partition on a SCSI drive
to another one on an IDE drive brought different message.  I include
it below.

When trying to immediatly reboot with this kernel a machine locks
up in the middle of fsck.  Luckily 2.2.18 does not have problems with
that or other disk operations for that matter.

Here is what I collected in logs this time before a machine went "poof".


kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753664
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753664
kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system 
zones - Block = 753665, count = 1
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753683
kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system 
zones - Block = 753686, count = 5
kernel: EXT2-fs error (device ide0(3,1)): ext2_add_entry: bad entry in directory 
#379108: inode out of bounds - offset=0, inode=4049125, rec_len=12, name_len=1
last message repeated 10 times
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753686
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753687
kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system 
zones - Block = 753688, count = 7
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753688
kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system 
zones - Block = 753689, count = 7
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753700
kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system 
zones - Block = 753702, count = 6
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753702
kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system 
zones - Block = 753705, count = 5
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753734
kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system 
zones - Block = 753739, count = 3
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753739
kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system 
zones - Block = 753746, count = 1
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753746
kernel: EXT2-fs error (device ide0(3,1)): ext2_free_blocks: Freeing blocks in system 
zones - Block = 753747, count = 7
kernel: EXT2-fs error (device ide0(3,1)): ext2_new_block: Allocating block in system 
zone - block = 753747

BTW - on a target disk there are no traces that somebody attempted to
copy something.

  Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: 2.4.1 not fully sane on Alpha - file systems

2001-02-01 Thread Michal Jaegermann

On Thu, Feb 01, 2001 at 10:46:12AM -0500, John Jasen wrote:
> On Wed, 31 Jan 2001, Michal Jaegermann wrote:
> 
> > I just tried to boot 2.4.1 kernel on Alpha UP1100.  This machine
> > happens to have two SCSI disks on sym53c875 controller and two IDE
> > drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE".
> 
> ALI M1535D pci-ide bridge, isn't it? That's what the specs on
> API's webpage seem to indicate.

'lspci' claims that this is:

"07.0  Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV]"

> 
> Try this for fun: dd if=/dev/hda of=/dev/null bs=4096, and see if it
> cronks out.

Probably.

> In my case, any serious I/O on the IDE drives quickly results in pretty
> technicolor on the VGA screen, and then a hard lockup.

No, no technicolor or other sounds effects.  The whole thing just
locks up with a power switch as the only option.

> Furthermore, after power-reset, 2.4.x, x=0 or 1, cannot successfully fsck
> the drives.  It hangs after about the 2nd-3rd partition, again in a hard
> lockup.

My box is much healtier than that.  Regardless if I booted into a file
system on a SCSI drive or on an IDE drive (I happen to have those
options although I prefer IDE - I have there something which I can loose
without any real pain :-) I can still fsck drives healthy after the
crash but I did NOT risk fsck under 2.4.1.  Things looks way too screwy
for this.

> 
> My WAG is that there are problems in the ALI driver.

Possibly, but I crashed the whole thing without mounting anything from
IDE drives at all.  There are still there but unused.  I simply managed
to get something in logs for the case described.  Note that errors
I quoted are from a device 08:05, i.e. SCSI driver (/dev/sda5 to be
more precise).  When my compiler went bonkers and started to read
clearly some random stuff instead of sources then the whole action was
happening on a SCSI drive.

 Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: 2.4.1 not fully sane on Alpha - file systems

2001-02-01 Thread John Jasen

On Wed, 31 Jan 2001, Michal Jaegermann wrote:

> I just tried to boot 2.4.1 kernel on Alpha UP1100.  This machine
> happens to have two SCSI disks on sym53c875 controller and two IDE
> drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE".

ALI M1535D pci-ide bridge, isn't it? That's what the specs on
API's webpage seem to indicate.

> It boots and in the first moment makes even a pretty good impression
> of beeing healthy.  But an attempt to compile something causes the
> whole setup to start behaving weird, with a compiler obviously unable
> to find both itself and the right sources, and the whole thing ends in
> a silent lockup.

Try this for fun: dd if=/dev/hda of=/dev/null bs=4096, and see if it
cronks out.

In my case, any serious I/O on the IDE drives quickly results in pretty
technicolor on the VGA screen, and then a hard lockup.

Furthermore, after power-reset, 2.4.x, x=0 or 1, cannot successfully fsck
the drives.  It hangs after about the 2nd-3rd partition, again in a hard
lockup.

I have to boot into 2.2.x to fsck the drives, make changes, and reboot to
hang the system.

My WAG is that there are problems in the ALI driver.

> On the second boot I tried to copy kernel sources from a SCSI to an
> IDE drive.  This time I got something in my logs and the same stuff
> was printed on my screen before everything lockded up really tight
> again (no sysrq).  Here it is:
>
>  kernel: attempt to access beyond end of device
>  kernel: 08:05: rw=0, want=198500353, limit=5779456
>  kernel: attempt to access beyond end of device
>  kernel: 08:05: rw=0, want=4294934529, limit=5779456
>  kernel: attempt to access beyond end of device
>  kernel: 08:05: rw=0, want=198500353, limit=5779456
>  kernel: EXT2-fs error (device sd(8,5)): ext2_readdir: bad entry in
>  directory #250255: directory entry across blocks - offset=0,
>  inode=198505472, rec_len=32768, name_len=255
>
> (and the machine dies at this point).

AIC7xxx controller, just recently started spewing errors very similar to
this -- amongst a host of others, as I was trying to get the UP1100 to use
a generic IDE interface rather than the ALI 15x3.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



2.4.1 not fully sane on Alpha - file systems

2001-01-31 Thread Michal Jaegermann

I just tried to boot 2.4.1 kernel on Alpha UP1100.  This machine
happens to have two SCSI disks on sym53c875 controller and two IDE
drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE".
It boots and in the first moment makes even a pretty good impression
of beeing healthy.  But an attempt to compile something causes the
whole setup to start behaving weird, with a compiler obviously unable
to find both itself and the right sources, and the whole thing ends in
a silent lockup.

On the second boot I tried to copy kernel sources from a SCSI to an
IDE drive.  This time I got something in my logs and the same stuff
was printed on my screen before everything lockded up really tight
again (no sysrq).  Here it is:

 kernel: attempt to access beyond end of device
 kernel: 08:05: rw=0, want=198500353, limit=5779456
 kernel: attempt to access beyond end of device
 kernel: 08:05: rw=0, want=4294934529, limit=5779456
 kernel: attempt to access beyond end of device
 kernel: 08:05: rw=0, want=198500353, limit=5779456
 kernel: EXT2-fs error (device sd(8,5)): ext2_readdir: bad entry in
 directory #250255: directory entry across blocks - offset=0,
 inode=198505472, rec_len=32768, name_len=255

(and the machine dies at this point).

There is nothing wrong with this device and a file system on it.
Copying the same way, or compiling the same sources, but when booted
with 2.2.18 does not present a whiff of trouble and e2fsck, luckily
enough, finds my file systems still in place.  One should be grateful
for small favours.

Anybody have seen something similar?

  Michal
  [EMAIL PROTECTED]

p.s. I find a bit humorous the fact that the code required to
recognize that one has _some_ partition table (I happen to have two
kinds at the moment) is billed in a config file as ADVANCED.
It did the job anyway. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/