Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fully sane on Alpha - file systems
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
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
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
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
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
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/