Menu
▾
▴
linux-apus-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(210) |
Jun
(169) |
Jul
(167) |
Aug
(128) |
Sep
(218) |
Oct
(120) |
Nov
(86) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(91) |
Feb
(179) |
Mar
(52) |
Apr
(56) |
May
(183) |
Jun
(62) |
Jul
(63) |
Aug
(49) |
Sep
(36) |
Oct
(35) |
Nov
(72) |
Dec
(30) |
| 2002 |
Jan
(53) |
Feb
(61) |
Mar
(56) |
Apr
(13) |
May
(1) |
Jun
(7) |
Jul
(80) |
Aug
(73) |
Sep
(30) |
Oct
(29) |
Nov
(8) |
Dec
(40) |
| 2003 |
Jan
(10) |
Feb
(2) |
Mar
(4) |
Apr
(9) |
May
(3) |
Jun
(19) |
Jul
(64) |
Aug
(53) |
Sep
(28) |
Oct
(7) |
Nov
(3) |
Dec
(21) |
| 2004 |
Jan
(11) |
Feb
(30) |
Mar
(18) |
Apr
(1) |
May
(13) |
Jun
(18) |
Jul
(13) |
Aug
|
Sep
(9) |
Oct
(5) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(10) |
Aug
(21) |
Sep
(7) |
Oct
(10) |
Nov
(6) |
Dec
|
| 2006 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(6) |
Oct
(10) |
Nov
(8) |
Dec
(3) |
| 2007 |
Jan
(3) |
Feb
(6) |
Mar
(1) |
Apr
(6) |
May
(10) |
Jun
(7) |
Jul
(13) |
Aug
(8) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Geert U. <ge...@li...> - 2002-11-08 10:50:46
|
On Fri, 8 Nov 2002, Alan Buxey wrote:
> unfortunately its not all plain sailing and happiness. when long, prolonged
> use of the IDE is undertaken (eg 'updatedb' ) the kernel has a nice
> Oops! I havent got the full net access etc back up yet...so will ksymoops
> this later to give more details... but suffice to say, i dont get this
> Ooops with the working 2.4.13-20011030 kernel (otherwise I wouldnt
> have been able to compile the 2.4.18 )
>
> I did note that at the end of the ooops! report it has the following lines.
>
>
> Kernel panic: Aiee, killing interupt handler!
> In interupt Handler - not syncing
>
> >>>reboot in 180 seconds (etc etc)
>
> these 2 lines dont appear to be normal.....
They mean the oops happens in the interrupt handler.
It would be nice to see the oops output, though (and ksymoops output, or
manually looked up addresses)...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Alan B. <al...@ms...> - 2002-11-08 10:46:40
|
hi,
> Great. I just committed a change which moves the call to the proper
> location. Could you try this one too (after reverting your changes)?
I'm not sure if I'm alone here.... but your change doesnt work
(i know...long delay in supplying this info but my HD died
on the day i checked out this CVS addition :-|)
Your change was the addition of
ide_ack_intr(hwif);
to line ~358 in ide-probe.c
But, the change by Krystian Baclawski ...which was done after some
information by you... DOES allow the kernel to get beyond IDE probing
and boot on the A1200. Line ~560 is the change...an addition of
hwif->hw.ack_intr(hwif);
as shown in the diff below
__restore_flags(flags); /* local CPU only */
if (hwif->hw.ack_intr && hwif->irq)
{
hwif->hw.ack_intr(hwif);
enable_irq(hwif->irq);
}
for (unit = 0; unit < MAX_DRIVES; ++unit) {
ide_drive_t *drive = &hwif->drives[unit];
if (drive->present) {
ide_tuneproc_t *tuneproc = HWIF(drive)->tuneproc;
if (tuneproc != NULL && drive->autotune == 1)
tuneproc(drive, 255);
}
}
unfortunately its not all plain sailing and happiness. when long, prolonged
use of the IDE is undertaken (eg 'updatedb' ) the kernel has a nice
Oops! I havent got the full net access etc back up yet...so will ksymoops
this later to give more details... but suffice to say, i dont get this
Ooops with the working 2.4.13-20011030 kernel (otherwise I wouldnt
have been able to compile the 2.4.18 )
I did note that at the end of the ooops! report it has the following lines.
Kernel panic: Aiee, killing interupt handler!
In interupt Handler - not syncing
>>>reboot in 180 seconds (etc etc)
these 2 lines dont appear to be normal.....
alan
|
|
From: Andreas <an...@po...> - 2002-11-06 17:27:27
|
Hello Michel Am 05-Nov-02 schrieb Michel D=E4nzer: > On Son, 2002-11-03 at 00:39, Andreas W=FCst wrote:=20 >>=20 >> I couldn't find any mouse device for a normal Amiga mouse connected to >> the mouseport. I luckily had some advice from earlier days to create i= t as >> follows: >>=20 >> # cd /dev/input >=20 > Do you really mean this or just /dev? Ok, caught him. The "problem" is non-debian specific, so no need to send followups to debian-boot (to be precise, it is neither apus speci= fic, it is specific to this strange guy who started this thread..). When helping Bj=F6rn Johansson, I sent him my XFConfig, which contained t= his /dev/input/amigamouse thingy. He wrote back that this wouldn't work, so I advised him how to create the amigamouse device. But then I wondered why = it isn't automatically included in the debian base installation. Well, it is, but not in /dev/input but in /dev. So how did I think it sho= uld be in /dev/input? I don't know!! I just don't know. I just sent him my co= nfig where it refers to /dev/input (which I neither know why this is like that= ), and he realised that this device doesn't exist. So please forget my post (lucky me i placed a question mark at the end of the subject, so I am not totally disgraced now..)! >> # mknod amigamouse c 10 4 >=20 > Or either of >=20 > MAKEDEV misc > MAKEDEV m68k-mice fine. Or just forget it.. PS: It would still be nice to have it mentioned during X configuration (a= s well as that Amiga users have to choose the BusMouse protocol).. --=20 Best wishes, Andi |
|
From: Marcus C. <ma...@mc...> - 2002-11-06 00:31:30
|
Following up on my own post: When I add debug printouts, the problem moves. So what we have here is a logic bomb. In both cases where I have been able to identify an actual codepoint where the kernel oopses though, it's been right after a call to __cli(), and the problem has been caused by a bogus value in r30/r31. So it almost looks like these registers are clobbered by an interrupt. Which would probably mean that the stack is trodden on somewhere inside the interrupt handler, causing the bogus values to be read back from the stack upon interrupt return. // Marcus |
|
From: Michel <da...@de...> - 2002-11-05 12:41:04
|
On Son, 2002-11-03 at 00:39, Andreas W=FCst wrote:=20 >=20 > I couldn't find any mouse device for a normal Amiga mouse connected to > the mouseport. I luckily had some advice from earlier days to create it a= s > follows: >=20 > # cd /dev/input Do you really mean this or just /dev? > # mknod amigamouse c 10 4 Or either of MAKEDEV misc MAKEDEV m68k-mice --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Marcus C. <ma...@mc...> - 2002-11-05 00:21:53
|
Ok, as promisied I started looking at the driver to see if I could find something out. I managed to get a real backtrace to throw at ksymoops this time: >>NIP; c00fe184 <scsi_release_command+48/18c> <===== Trace; c3f53c14 <_end+3cf073c/45ddb88> Trace; c00fe778 <scsi_wait_req+bc/d4> Trace; c011448c <sr_disk_status+24/f0> Trace; c011520c <sr_cd_check+e8/590> Trace; c0112754 <sr_media_change+cc/10c> Trace; c011686c <media_changed+64/b0> Trace; c0116900 <cdrom_media_changed+48/60> Trace; c003de7c <check_disk_change+54/d0> Trace; c0115bc0 <cdrom_open+c0/11c> Trace; c003e018 <do_open+b0/1f4> Trace; c003e1c4 <blkdev_get+68/7c> Trace; c003c8f0 <get_sb_bdev+f8/310> Trace; c003d0b8 <do_kern_mount+b4/1dc> Trace; c00516b0 <do_add_mount+2c/158> Trace; c0051a68 <do_mount+180/194> Trace; c0051b20 <sys_mount+a4/f4> Trace; c0003e9c <ret_from_syscall_1+0/b4> Trace; ffffffff <END_OF_CODE+3b7a9930/????> Looking at the disassembly of scsi_release_command, I found that the offending instruction was generated from the first atomic_dec() invocation in the inline __scsi_release_command() function (in scsi.c). When the kernel oopses, SCpnt is 0xc2275d28 (which is suspicious in itself, as all previous invocations have had pointers starting with 0xc3f) and SCpnt->host is NULL. So, AFAICT, scsi_release_command() was called with a phony SCpnt. scsi_wait_req() gets the SCpnt it calls scsi_release_command() with from SRpnt->sr_command. Maybe this field is not initialized/cleared appropriately somewhere? I don't have time to dig further into it right now, but maybe I'll give it another shot tomorrow. Btw, turning on DEBUG_NCR53C8XX, I noticed that there were _lots_ of calls to ncr53c8xx_intr() even though no SCSI device was accessed at all. Is this intentional? It could be a potential performance problem perhaps? // Marcus |
|
From: Andreas <an...@po...> - 2002-11-02 23:43:13
|
Hi In the light of an upcoming 3.0r1 release I wanted to bring up an issue which stroke me a bit during installation. I couldn't find any mouse device for a normal Amiga mouse connected to the mouseport. I luckily had some advice from earlier days to create it as follows: # cd /dev/input # mknod amigamouse c 10 4 I guess it would be a bit annoying for a newbie to not find any information about amiga mice nor having any working device for it anyway, which means you don't have any mouse support at all. May it be a good idea to add this device to a base installation, or does it just duplicate another already existing device (but of which noone knows that it has to be chosen as an Amiga mouse device)? OTOH, it is not that useful to have a device but nobody knowing of it. So it should maybe also be mentioned during X or gpm configuration, but this seems to be another story.. [ sent to debian-boot and linux-apus-devel ] -- Best wishes, Andi |
|
From: Marcus C. <ma...@mc...> - 2002-10-28 18:19:57
|
Rene Brothuhn <re...@we...> writes: > If I have the time, I will try to find out whats wrong in the > driver. There are also some configuration stuff in the driver which is > not really "clean". Maybe some of the problems will go if the driver > is cleaned up. > > > So if you want to work on the driver, feel free. Ok, I'll take a look at it next week. // Marcus |
|
From: Rene B. <re...@we...> - 2002-10-28 18:00:27
|
On 2002.10.25 16:33 Marcus Comstedt wrote: > > Rene Brothuhn writes: > > > > Hello! > > > > > > The problems with CDROM drives are already known. Other devices (HD and > > ZIP) seems working fine. > > But thanks for the advice! > > Hi Renè. > > So, does this mean you are working on a solution, or do you need help? If I have the time, I will try to find out whats wrong in the driver. There are also some configuration stuff in the driver which is not really "clean". Maybe some of the problems will go if the driver is cleaned up. So if you want to work on the driver, feel free. Ciao, Renè |
|
From: Marcus C. <ma...@mc...> - 2002-10-25 14:33:46
|
Rene Brothuhn writes: >=20 > Hello! >=20=20 >=20=20 > The problems with CDROM drives are already known. Other devices (HD and=20 > ZIP) seems working fine. > But thanks for the advice! Hi Ren=E8. So, does this mean you are working on a solution, or do you need help? Using SCSI HD and ZIP from Linux isn't very useful to me unfortunately, but using the CD/DVD drives sure would be. (In response to Michels reply I've included a ksymoops run on the oopses I already posted, not that I think it makes much difference since the kernel has jumped out into nothingness after following a bad pointer as far as I can see, so the backtraces are unusable...) // Marcus Oct 24 13:14:13 amicus kernel: Oops: kernel access of bad area, sig: 11=20 Oct 24 13:14:13 amicus kernel: NIP: C3F4C000 XER: 20000000 LR: C3F4C000 SP:= C070FC20 REGS: c070fb70 TRAP: 0400 Not tainted=20 Using defaults from ksymoops -t elf32-powerpc -a powerpc:common Oct 24 13:14:13 amicus kernel: MSR: 10009072 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR:= 11=20 Oct 24 13:14:13 amicus kernel: TASK =3D c070e000[696] 'mount' Last syscall:= 21=20=20 Oct 24 13:14:13 amicus kernel: last math c070e000 last altivec 00000000=20 Oct 24 13:14:13 amicus kernel: GPR00: C3F4C000 C070FC20 C070E000 00000000 0= 0001072 00000001 C02C0350 C02C0348=20=20 Oct 24 13:14:13 amicus kernel: GPR08: C3F65000 00000000 00000100 0000000E 8= 2008488 1002848C 00000000 00000000=20=20 Oct 24 13:14:13 amicus kernel: GPR16: 7FFFF5CC 7FFFF5D8 7FFFF5C8 00000001 0= 0009072 0870FF40 00000000 C07D9000=20=20 Oct 24 13:14:13 amicus kernel: GPR24: 00000001 C0776DE0 C070FD28 C0230000 C= 3F53C14 C3F4D880 00520109 00140100=20=20 Oct 24 13:14:13 amicus kernel: Call backtrace:=20=20 Oct 24 13:14:13 amicus kernel: C3F4C000=20=20 Warning (Oops_read): Code line not seen, dumping what data is available >>NIP; c3f4c000 <_end+3ce8b28/45f0b88> <=3D=3D=3D=3D=3D Trace; c3f4c000 <_end+3ce8b28/45f0b88> Oct 24 13:15:56 amicus kernel: Oops: kernel access of bad area, sig: 11=20 Oct 24 13:15:56 amicus kernel: NIP: 00000000 XER: 20000000 LR: 00000000 SP:= C2EC7C00 REGS: c2ec7b50 TRAP: 0400 Not tainted=20 Oct 24 13:15:56 amicus kernel: MSR: 40009072 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR:= 11=20 Oct 24 13:15:56 amicus kernel: TASK =3D c2ec6000[717] 'mount' Last syscall:= 7=20=20 Oct 24 13:15:56 amicus kernel: last math 00000000 last altivec 00000000=20 Oct 24 13:15:56 amicus kernel: GPR00: 00000000 C2EC7C00 C2EC6000 00000000 0= 0001072 00000001 C02C0350 C02C0348=20=20 Oct 24 13:15:56 amicus kernel: GPR08: C3F65000 0000000D 00000100 0000000E 8= 2008448 1001E8F8 00000000 00000000=20=20 Oct 24 13:15:56 amicus kernel: GPR16: 7FFFF68C 7FFFF698 7FFFF688 00000000 0= 0009072 0AEC7F40 00000000 C2C05000=20=20 Oct 24 13:15:56 amicus kernel: GPR24: 00000001 C0B9C2C0 C2EC7D28 C0230000 C= 3F53C7C 00005305 00000001 C2EC7C68=20=20 Oct 24 13:15:56 amicus kernel: Call backtrace:=20=20 Oct 24 13:15:56 amicus kernel: 00000000=20=20 Warning (Oops_read): Code line not seen, dumping what data is available >>NIP; 00000000 Before first symbol Trace; 00000000 Before first symbol |
|
From: Rene B. <re...@we...> - 2002-10-25 11:57:44
|
On 2002.10.24 17:47 Marcus Comstedt wrote: > > Hello. > > Yesterday, I found out that there has finally been CSPPC UW-SCSI > support added to the APUS kernel. I was really happy about this and > would like to applaud the responsible party/ies for this effort. > > However, while mounting a hard disk worked just fine, I could not get > it to mount either a normal CD-ROM or my DVD-RAM (which was the unit I > actually wanted to use). Hello! The problems with CDROM drives are already known. Other devices (HD and ZIP) seems working fine. But thanks for the advice! Ciao, Renè |
|
From: Michel <mi...@da...> - 2002-10-25 11:39:35
|
On Don, 2002-10-24 at 17:47, Marcus Comstedt wrote:=20 >=20 > Yesterday, I found out that there has finally been CSPPC UW-SCSI > support added to the APUS kernel. I was really happy about this and > would like to applaud the responsible party/ies for this effort. >=20 > However, while mounting a hard disk worked just fine, I could not get > it to mount either a normal CD-ROM or my DVD-RAM (which was the unit I > actually wanted to use). >=20 > The following messages appeared: >=20 > [root@amicus marcus]# mount /dev/scd0 /mnt/cdrom > mount: block device /dev/scd0 is write-protected, mounting read-only > Oops: kernel access of bad area, sig: 11=20 [...] The oopsen are incomprehensible unless being decoded by ksymoops. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Marcus C. <ma...@mc...> - 2002-10-24 15:47:50
|
Hello. Yesterday, I found out that there has finally been CSPPC UW-SCSI support added to the APUS kernel. I was really happy about this and would like to applaud the responsible party/ies for this effort. However, while mounting a hard disk worked just fine, I could not get it to mount either a normal CD-ROM or my DVD-RAM (which was the unit I actually wanted to use). The following messages appeared: [root@amicus marcus]# mount /dev/scd0 /mnt/cdrom mount: block device /dev/scd0 is write-protected, mounting read-only Oops: kernel access of bad area, sig: 11 NIP: C3F4C000 XER: 20000000 LR: C3F4C000 SP: C070FC20 REGS: c070fb70 TRAP: 0400 Not tainted MSR: 10009072 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c070e000[696] 'mount' Last syscall: 21 last math c070e000 last altivec 00000000 GPR00: C3F4C000 C070FC20 C070E000 00000000 00001072 00000001 C02C0350 C02C0348 GPR08: C3F65000 00000000 00000100 0000000E 82008488 1002848C 00000000 00000000 GPR16: 7FFFF5CC 7FFFF5D8 7FFFF5C8 00000001 00009072 0870FF40 00000000 C07D9000 GPR24: 00000001 C0776DE0 C070FD28 C0230000 C3F53C14 C3F4D880 00520109 00140100 Call backtrace: C3F4C000 Segmentation fault [root@amicus marcus]# mount -t udf -o ro /dev/scd1 /mnt/cdrom udf: registering filesystem Oops: kernel access of bad area, sig: 11 NIP: 00000000 XER: 20000000 LR: 00000000 SP: C2EC7C00 REGS: c2ec7b50 TRAP: 0400 Not tainted MSR: 40009072 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c2ec6000[717] 'mount' Last syscall: 7 last math 00000000 last altivec 00000000 GPR00: 00000000 C2EC7C00 C2EC6000 00000000 00001072 00000001 C02C0350 C02C0348 GPR08: C3F65000 0000000D 00000100 0000000E 82008448 1001E8F8 00000000 00000000 GPR16: 7FFFF68C 7FFFF698 7FFFF688 00000000 00009072 0AEC7F40 00000000 C2C05000 GPR24: 00000001 C0B9C2C0 C2EC7D28 C0230000 C3F53C7C 00005305 00000001 C2EC7C68 Call backtrace: 00000000 Segmentation fault [root@amicus marcus]# I'm including the whole syslog at the end of the mail, in case it's of interrest to anybody. Is there anything I can do to help debug this? I'd really like to be able to use my DVD-RAM from Linux as well... // Marcus Oct 24 13:08:59 amicus syslogd 1.3-3: restart. Oct 24 13:08:59 amicus syslog: syslogd startup succeeded Oct 24 13:08:59 amicus syslog: klogd startup succeeded Oct 24 13:08:59 amicus kernel: klogd 1.3-3, log source = /proc/kmsg started. Oct 24 13:08:59 amicus kernel: Inspecting /boot/System.map-2.4.18 Oct 24 13:09:00 amicus identd: identd startup succeeded Oct 24 13:08:47 amicus rc.sysinit: Mounting proc filesystem succeeded Oct 24 13:08:47 amicus sysctl: net.ipv4.ip_forward = 0 Oct 24 13:08:47 amicus sysctl: net.ipv4.conf.all.rp_filter = 1 Oct 24 13:08:47 amicus rc.sysinit: Configuring kernel parameters succeeded Oct 24 13:08:47 amicus date: Thu Oct 24 13:00:45 CEST 2002 Oct 24 13:08:47 amicus rc.sysinit: Setting clock (localtime): Thu Oct 24 13:00:45 CEST 2002 succeeded Oct 24 13:08:47 amicus rc.sysinit: Loading default keymap succeeded Oct 24 13:08:47 amicus rc.sysinit: Activating swap partitions succeeded Oct 24 13:08:47 amicus rc.sysinit: Setting hostname amicus.mc.pp.se succeeded Oct 24 13:08:47 amicus rc.sysinit: Setting NIS domain name mc.pp.se succeeded Oct 24 13:08:47 amicus fsck: /dev/hda1 has reached maximal mount count, check forced. Oct 24 13:08:47 amicus fsck: /dev/hda1: | Oct 24 13:08:47 amicus last message repeated 3 times Oct 24 13:08:47 amicus fsck: /dev/hda1: 149466/798720 files (3.1% non-contiguous), 2877500/3194352 blocks Oct 24 13:08:47 amicus rc.sysinit: Checking root filesystem succeeded Oct 24 13:08:47 amicus rc.sysinit: Remounting root filesystem in read-write mode succeeded Oct 24 13:08:50 amicus rc.sysinit: Finding module dependencies succeeded Oct 24 13:08:50 amicus rc.sysinit: Checking filesystems succeeded Oct 24 13:08:51 amicus rc.sysinit: Mounting local filesystems succeeded Oct 24 13:08:51 amicus rc.sysinit: Turning on user and group quotas for local filesystems succeeded Oct 24 13:08:52 amicus rc.sysinit: Enabling swap space succeeded Oct 24 13:08:52 amicus init: Entering runlevel: 3 Oct 24 13:08:53 amicus sysctl: net.ipv4.ip_forward = 0 Oct 24 13:08:53 amicus sysctl: net.ipv4.conf.all.rp_filter = 1 Oct 24 13:08:53 amicus network: Setting network parameters succeeded Oct 24 13:08:54 amicus network: Bringing up interface lo succeeded Oct 24 13:08:55 amicus network: Bringing up interface eth0 succeeded Oct 24 13:08:56 amicus portmap: portmap startup succeeded Oct 24 13:08:56 amicus rpc.lockd: lockdsvc: Invalid argument Oct 24 13:08:56 amicus nfslock: rpc.lockd startup failed Oct 24 13:08:56 amicus nfslock: rpc.statd startup succeeded Oct 24 13:08:57 amicus ypbind: ypbind startup succeeded Oct 24 13:08:58 amicus autofs: autofs startup succeeded Oct 24 13:08:58 amicus automount[372]: starting automounter version 3.1.4, path = /misc, maptype = file, mapname = /etc/auto.misc Oct 24 13:08:58 amicus random: Initializing random number generator succeeded Oct 24 13:08:58 amicus netfs: Mounting other filesystems succeeded Oct 24 13:09:00 amicus kernel: Loaded 17174 symbols from /boot/System.map-2.4.18. Oct 24 13:09:00 amicus kernel: Symbols match kernel version 2.4.18. Oct 24 13:09:00 amicus kernel: Loaded 27 symbols from 2 modules. Oct 24 13:09:00 amicus kernel: Memory BAT mapping: BAT2=32Mb, BAT3=16Mb, residual: 15Mb Oct 24 13:09:00 amicus kernel: Total memory = 63MB; using 256kB for hash table (at c0280000) Oct 24 13:09:00 amicus kernel: Linux version 2.4.18 (ma...@am...) (gcc version 3.0.4) #2 Wed Oct 23 22:40:12 CEST 2002 Oct 24 13:09:00 amicus kernel: Amiga hardware found: [A4000] VIDEO BLITTER AUDIO FLOPPY A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA LISA ALICE_PAL ZORRO3 Oct 24 13:09:00 amicus kernel: On node 0 totalpages: 16256 Oct 24 13:09:00 amicus kernel: zone(0): 16256 pages. Oct 24 13:09:00 amicus kernel: zone(1): 0 pages. Oct 24 13:09:00 amicus kernel: zone(2): 0 pages. Oct 24 13:09:00 amicus kernel: Kernel command line: root=/dev/hda1 video=pm2fb:mode:800x600-60 nobats 60nsram Oct 24 13:09:00 amicus kernel: ioremap: fffc0000 (00001000) -> fdfff000 Oct 24 13:09:00 amicus kernel: ioremap: fffe0000 (00001000) -> fdffe000 Oct 24 13:09:00 amicus kernel: APUS: BATs=0, BUS=67MHz, RAM=60ns, PCI bridge=1 Oct 24 13:09:01 amicus kernel: time_init: decrementer frequency = 16.503517 MHz Oct 24 13:09:01 amicus kernel: Console: colour dummy device 80x25 Oct 24 13:09:01 amicus kernel: Calibrating delay loop... 395.67 BogoMIPS Oct 24 13:09:01 amicus kernel: Memory: 61284k available (1604k kernel code, 596k data, 248k init, 0k highmem) Oct 24 13:09:01 amicus kernel: Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Oct 24 13:09:01 amicus kernel: Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) Oct 24 13:09:01 amicus kernel: Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Oct 24 13:09:01 amicus kernel: Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Oct 24 13:09:01 amicus kernel: Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Oct 24 13:09:01 amicus kernel: POSIX conformance testing by UNIFIX Oct 24 13:09:01 amicus kernel: PCI: Probing PCI hardware Oct 24 13:09:01 amicus kernel: Memory resource not set for host bridge 0 Oct 24 13:09:01 amicus kernel: apus_pcibios_fixup: PCI mem resource requested Oct 24 13:09:01 amicus kernel: PCI: Cannot allocate resource region 1 of PCI bridge 0 Oct 24 13:09:01 amicus kernel: PCI: resource is e0000000..fffc0000 (200), parent c01ccc54 Oct 24 13:09:01 amicus kernel: PCI:00:01.0: Resource 0: ef000000-ef01ffff (f=200) Oct 24 13:09:01 amicus kernel: PCI:00:01.0: Resource 1: e1000000-e17fffff (f=200) Oct 24 13:09:01 amicus kernel: PCI:00:01.0: Resource 2: e1000000-e17fffff (f=200) Oct 24 13:09:01 amicus kernel: PCI: Cannot allocate resource region 2 of device 00:01.0 Oct 24 13:09:01 amicus kernel: PCI: parent is c01cc8d8: e0000000-fffc0000 (f=200) Oct 24 13:09:01 amicus kernel: PCI: Switching off ROM of 00:01.0 Oct 24 13:09:01 amicus kernel: Zorro: Probing AutoConfig expansion devices: 5 devices Oct 24 13:09:01 amicus kernel: Linux NET4.0 for Linux 2.4 Oct 24 13:09:01 amicus kernel: Based upon Swansea University Computer Society NET3.039 Oct 24 13:09:01 amicus kernel: Initializing RT netlink socket Oct 24 13:09:01 amicus kernel: Starting kswapd Oct 24 13:09:01 amicus kernel: Journalled Block Device driver loaded Oct 24 13:09:01 amicus kernel: ioremap: fffc0000 (00001000) -> c401a000 Oct 24 13:09:01 amicus kernel: ioremap: fffe0000 (00001000) -> c401c000 Oct 24 13:09:01 amicus kernel: ioremap: e0000000 (00800000) -> c401e000 Oct 24 13:09:01 amicus kernel: ioremap: ef010000 (00010000) -> c481f000 Oct 24 13:09:01 amicus kernel: Console: switching to colour frame buffer device 100x37 Oct 24 13:09:01 amicus kernel: fb0: CVisionPPC/BVisionPPC (Permedia2), using 8192K of video memory. Oct 24 13:09:01 amicus kernel: fb1: Amiga AGA frame buffer device, using 1280K of video memory Oct 24 13:09:01 amicus kernel: pty: 256 Unix98 ptys configured Oct 24 13:09:01 amicus kernel: Amiga-builtin serial driver version 4.30 Oct 24 13:09:01 amicus kernel: ttyS00 is the amiga builtin serial port Oct 24 13:09:01 amicus kernel: Amiga mouse installed. Oct 24 13:09:01 amicus kernel: Generic RTC Driver v1.02 Oct 24 13:09:01 amicus kernel: block: 128 slots per queue, batch=32 Oct 24 13:09:01 amicus kernel: RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Oct 24 13:09:01 amicus kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31 Oct 24 13:09:01 amicus kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Oct 24 13:09:01 amicus kernel: ide0: Gayle IDE interface (A4000 style) Oct 24 13:09:01 amicus kernel: hda: Maxtor 32049H2, ATA DISK drive Oct 24 13:09:01 amicus kernel: ide0 at 80dd2020 on irq 0x0000000c Oct 24 13:09:01 amicus kernel: hda: 40021632 sectors (20491 MB) w/2048KiB Cache, CHS=39704/16/63 Oct 24 13:09:01 amicus kernel: ide-floppy driver 0.97.sv Oct 24 13:09:01 amicus kernel: Partition check: Oct 24 13:09:01 amicus kernel: hda: RDSK hda1 hda2 hda3 hda4 Oct 24 13:09:01 amicus kernel: FD: probing units Oct 24 13:09:01 amicus kernel: found fd0 Oct 24 13:09:01 amicus kernel: loop: loaded (max 8 devices) Oct 24 13:09:01 amicus kernel: No Ariadne II or X-Surf ethernet card found. Oct 24 13:09:01 amicus kernel: eth0: Ariadne at 0x00eb0000, Ethernet Address 00:60:30:00:1c:e9 Oct 24 13:09:01 amicus kernel: eth1: Ariadne at 0x00ec0000, Ethernet Address 00:60:30:00:1a:88 Oct 24 13:09:01 amicus kernel: ide-floppy driver 0.97.sv Oct 24 13:09:01 amicus kernel: SCSI subsystem driver Revision: 1.00 Oct 24 13:09:01 amicus kernel: ncr53c8xx: 53c770 detected Oct 24 13:09:01 amicus kernel: ncr53c770-0: rev=0x00, base=0xf40000, io_port=0x0, irq=12 Oct 24 13:09:01 amicus kernel: ncr53c770-0: using memory mapped IO at virtual address 0x80f40000 Oct 24 13:09:01 amicus kernel: ncr53c770-0: ID 7, Fast-20, Parity Checking Oct 24 13:09:01 amicus kernel: ncr53c770-0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/c0/21/00/00/04 Oct 24 13:09:01 amicus kernel: ncr53c770-0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/c0/21/00/00/04 Oct 24 13:09:01 amicus kernel: ncr53c770-0: on-chip RAM at 0xf41000 Oct 24 13:09:01 amicus kernel: ncr53c770-0: resetting, command processing suspended for 2 seconds Oct 24 13:09:01 amicus kernel: ncr53c770-0: restart (scsi reset). Oct 24 13:09:01 amicus kernel: ncr53c770-0: enabling clock multiplier Oct 24 13:09:01 amicus kernel: ncr53c770-0: Downloading SCSI SCRIPTS. Oct 24 13:09:01 amicus kernel: scsi0 : ncr53c770-3.4.3-20010212 Oct 24 13:09:01 amicus kernel: ncr53c770-0: command processing resumed Oct 24 13:09:01 amicus kernel: Vendor: QUANTUM Model: VIKING 4.5 WSE Rev: 8808 Oct 24 13:09:01 amicus kernel: Type: Direct-Access ANSI SCSI revision: 02 Oct 24 13:09:01 amicus kernel: Vendor: NEC Model: CD-ROM DRIVE:222 Rev: 3.0i Oct 24 13:09:01 amicus kernel: Type: CD-ROM ANSI SCSI revision: 02 Oct 24 13:09:01 amicus kernel: Vendor: TOSHIBA Model: SD-W1101 DVD-RAM Rev: 1029 Oct 24 13:09:01 amicus kernel: Type: CD-ROM ANSI SCSI revision: 02 Oct 24 13:09:01 amicus kernel: Attached scsi disk sda at scsi0, channel 0, id 2, lun 0 Oct 24 13:09:01 amicus kernel: ncr53c770-0-<2,*>: WIDE SCSI (16 bit) enabled. Oct 24 13:09:01 amicus kernel: ncr53c770-0-<2,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 16) Oct 24 13:09:01 amicus kernel: SCSI device sda: 8899737 512-byte hdwr sectors (4557 MB) Oct 24 13:09:01 amicus kernel: sda: RDSK sda1 sda2 sda3 sda4 sda5 sda6 Oct 24 13:09:01 amicus kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0 Oct 24 13:09:01 amicus kernel: Attached scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0 Oct 24 13:09:01 amicus atd: atd startup succeeded Oct 24 13:09:01 amicus kernel: ncr53c770-0-<3,*>: FAST-10 SCSI 6.7 MB/s (150 ns, offset 15) Oct 24 13:09:01 amicus kernel: sr0: scsi-1 drive Oct 24 13:09:01 amicus kernel: Uniform CD-ROM driver Revision: 3.12 Oct 24 13:09:01 amicus kernel: ncr53c770-0-<4,*>: target did not report SYNC. Oct 24 13:09:01 amicus kernel: sr1: scsi3-mmc drive: 0x/0x dvd-ram cd/rw xa/form2 cdda tray Oct 24 13:09:01 amicus kernel: NET4: Linux TCP/IP 1.0 for NET4.0 Oct 24 13:09:01 amicus kernel: IP Protocols: ICMP, UDP, TCP Oct 24 13:09:01 amicus kernel: IP: routing cache hash table of 512 buckets, 4Kbytes Oct 24 13:09:01 amicus kernel: TCP: Hash tables configured (established 4096 bind 8192) Oct 24 13:09:01 amicus kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Oct 24 13:09:01 amicus kernel: VFS: Mounted root (ext2 filesystem) readonly. Oct 24 13:09:01 amicus kernel: Freeing unused kernel memory: 248k init Oct 24 13:09:01 amicus kernel: Adding Swap: 131032k swap-space (priority -1) Oct 24 13:09:01 amicus kernel: Installing knfsd (copyright (C) 1996 ok...@mo...). Oct 24 13:09:02 amicus crond: crond startup succeeded Oct 24 13:09:02 amicus inet: inetd startup succeeded Oct 24 13:09:03 amicus sshd: Starting sshd: Oct 24 13:09:03 amicus sshd: sshd startup succeeded Oct 24 13:09:03 amicus sshd: ^[[60G Oct 24 13:09:03 amicus sshd[515]: Server listening on 0.0.0.0 port 22. Oct 24 13:09:03 amicus sshd[515]: Generating 768 bit RSA key. Oct 24 13:09:03 amicus sshd: Oct 24 13:09:03 amicus rc: Starting sshd succeeded Oct 24 13:09:04 amicus lpd: lpd startup succeeded Oct 24 13:09:04 amicus lpd[531]: restarted Oct 24 13:09:04 amicus keytable: Loading keymap: Oct 24 13:09:04 amicus keytable: Loading /usr/lib/kbd/keymaps/amiga/amiga-se.kmap.gz Oct 24 13:09:04 amicus keytable: Loading system font: Oct 24 13:09:05 amicus rc: Starting keytable succeeded Oct 24 13:09:05 amicus sshd[515]: RSA key generation complete. Oct 24 13:09:07 amicus xfs: xfs startup succeeded Oct 24 13:09:07 amicus xfs: Warning: The directory "/usr/share/fonts/default/TrueType" does not exist. Oct 24 13:09:07 amicus xfs: Entry deleted from font path. Oct 24 13:09:08 amicus linuxconf: Linuxconf final setup Oct 24 13:09:10 amicus rc: Starting linuxconf succeeded Oct 24 13:13:32 amicus PAM_pwdb[636]: (login) session opened for user marcus by LOGIN(uid=0) Oct 24 13:13:55 amicus PAM_pwdb[677]: (su) session opened for user root by marcus(uid=2042) Oct 24 13:14:13 amicus kernel: Oops: kernel access of bad area, sig: 11 Oct 24 13:14:13 amicus kernel: NIP: C3F4C000 XER: 20000000 LR: C3F4C000 SP: C070FC20 REGS: c070fb70 TRAP: 0400 Not tainted Oct 24 13:14:13 amicus kernel: MSR: 10009072 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 Oct 24 13:14:13 amicus kernel: TASK = c070e000[696] 'mount' Last syscall: 21 Oct 24 13:14:13 amicus kernel: last math c070e000 last altivec 00000000 Oct 24 13:14:13 amicus kernel: GPR00: C3F4C000 C070FC20 C070E000 00000000 00001072 00000001 C02C0350 C02C0348 Oct 24 13:14:13 amicus kernel: GPR08: C3F65000 00000000 00000100 0000000E 82008488 1002848C 00000000 00000000 Oct 24 13:14:13 amicus kernel: GPR16: 7FFFF5CC 7FFFF5D8 7FFFF5C8 00000001 00009072 0870FF40 00000000 C07D9000 Oct 24 13:14:13 amicus kernel: GPR24: 00000001 C0776DE0 C070FD28 C0230000 C3F53C14 C3F4D880 00520109 00140100 Oct 24 13:14:13 amicus kernel: Call backtrace: Oct 24 13:14:13 amicus kernel: C3F4C000 Oct 24 13:15:19 amicus PAM_pwdb[700]: (su) session opened for user root by marcus(uid=2042) Oct 24 13:15:56 amicus kernel: udf: registering filesystem Oct 24 13:15:56 amicus kernel: Oops: kernel access of bad area, sig: 11 Oct 24 13:15:56 amicus kernel: NIP: 00000000 XER: 20000000 LR: 00000000 SP: C2EC7C00 REGS: c2ec7b50 TRAP: 0400 Not tainted Oct 24 13:15:56 amicus kernel: MSR: 40009072 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 Oct 24 13:15:56 amicus kernel: TASK = c2ec6000[717] 'mount' Last syscall: 7 Oct 24 13:15:56 amicus kernel: last math 00000000 last altivec 00000000 Oct 24 13:15:56 amicus kernel: GPR00: 00000000 C2EC7C00 C2EC6000 00000000 00001072 00000001 C02C0350 C02C0348 Oct 24 13:15:56 amicus kernel: GPR08: C3F65000 0000000D 00000100 0000000E 82008448 1001E8F8 00000000 00000000 Oct 24 13:15:56 amicus kernel: GPR16: 7FFFF68C 7FFFF698 7FFFF688 00000000 00009072 0AEC7F40 00000000 C2C05000 Oct 24 13:15:56 amicus kernel: GPR24: 00000001 C0B9C2C0 C2EC7D28 C0230000 C3F53C7C 00005305 00000001 C2EC7C68 Oct 24 13:15:56 amicus kernel: Call backtrace: Oct 24 13:15:56 amicus kernel: 00000000 Oct 24 13:16:35 amicus PAM_pwdb[700]: (su) session closed for user root Oct 24 13:20:23 amicus PAM_pwdb[725]: (su) session opened for user root by marcus(uid=2042) |
|
From: <no...@so...> - 2002-10-16 14:23:34
|
Feature Requests item #564304, was opened at 2002-06-04 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355907&aid=564304&group_id=5907 Category: Kernel Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Elbox Fast ATA II Initial Comment: Anybody ever had an idea to write driver for Elbox FastATA II Controller? Why Linux 2.4.18 doesn't boot with it. If someone gives me hardware specification I'll write driver. ---------------------------------------------------------------------- Comment By: Krystian Bac³awski (cahirwpz) Date: 2002-10-16 16:23 Message: Logged In: YES user_id=574906 Yep, I know, because I'm the person that have that specification. The first problem is that I'm not experienced in writing drivers. The second is that I'm far away from my amiga (studies). The third is lack of some structures in cvs kernel tree (as Geert told) so I cannot implement many things (FastATA is really diffrent from PC IDE controllers). Currently I've managed to use hda/hdb in PIO3/4/5 16bit mode (1.5-3 MB per second). Driver support for many features of FastATA is very limited. I'm looking for people that're willing to test this very experimental driver. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-16 13:26 Message: Logged In: NO According to Darek Dulian (Elbox) they have made available FastATA technical documentation for people interetsed in writing linux drivers for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355907&aid=564304&group_id=5907 |
|
From: <no...@so...> - 2002-10-16 11:26:56
|
Feature Requests item #564304, was opened at 2002-06-04 04:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355907&aid=564304&group_id=5907 Category: Kernel Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Elbox Fast ATA II Initial Comment: Anybody ever had an idea to write driver for Elbox FastATA II Controller? Why Linux 2.4.18 doesn't boot with it. If someone gives me hardware specification I'll write driver. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-16 04:26 Message: Logged In: NO According to Darek Dulian (Elbox) they have made available FastATA technical documentation for people interetsed in writing linux drivers for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355907&aid=564304&group_id=5907 |
|
From: schneider <sch...@te...> - 2002-10-16 10:33:54
|
After some more testing, i have my uw scsi running without locks. I disconnected my cdrom (plextor32xultrascsi) and the problems are gone. I never tried without the cdrom (stupid me;-)). Is this an error of the low-level driver??? I´ll try the a4000t build in scsi next, maybe it works also without. It is really smoooooth running with the scsi driver, not so slow with the ide! Axel |
|
From: <no...@so...> - 2002-10-14 14:50:03
|
Feature Requests item #623057, was opened at 2002-10-14 07:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355907&aid=623057&group_id=5907 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Mediator Support Initial Comment: Any Amiga/Unix guru can support the mediator pci in the apus linux?? I love to run apus linux but since I sell my bvision I cant. I think taht is the best selled amiga hardware In a couple of years and can be very important to support. Thx for read my lame petition (Its easy request than develop) d0rA^SKT ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355907&aid=623057&group_id=5907 |
|
From: Geert U. <ge...@li...> - 2002-10-13 13:38:53
|
On Wed, 25 Sep 2002, [iso-8859-2] Krystian Bac=B3awski wrote:
> It's possible to change ide_setup_ports() arguments after this call
> (eg. after probing devices, I want to switch to another PIO mode, so I
> have to change register set and also fastata_ack_intr_a1200 procedure).
> How to achive this ?
In 2.5.x (and soon in 2.4.x), you can have interface-specific ide_io_ops.=
That
way you can more easily change the base address for a drive, depending on=
the
PIO mode.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org
In personal conversations with technical people, I call myself a hacker. =
But
when I'm talking to journalists I just say "programmer" or something like=
that.
-- Linus Torvalds
|
|
From: Michel <mi...@da...> - 2002-10-12 12:57:26
|
On Sam, 2002-10-12 at 11:53, Giorgio Terzi wrote: > Alle 14:50, venerd=EC 11 ottobre 2002, Michel D=E4nzer ha scritto: >=20 > > > The warbled text problem i signaled succedes only in the X text windo= ws > > > as Xterm or Mozilla and so on. I think this is a driver's limitation > > > because with 1024x768x16 resolution this succedes only when the machi= ne > > > is very stressed but with 1152x864x16 and over this succedes everytim= e i > > > open a window. With these high resolutions it warbles also the graphi= cs. > > > > Sounds like bus contention and/or synchronization problems in the 2D > > acceleration code. >=20 > I think that what you are saying is also (or something near) the reason > why the framebuffer crashes after a vterm exchange from X . > Is it possible that X is not signalled to release its resources and go to= =20 > sleep ? It does, but one potential problem I see is that the glint driver still lets the driver independent code call fbdevHW functions directly. I've modified the radeon driver in DRI CVS to always go through driver functions and make sure the acceleration engine is idle before calling an fbdevHW function. You may want to take a look at that and try something similar with the glint driver. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: schneider <sch...@te...> - 2002-10-12 10:26:08
|
Giorgio Terzi wrote: > Alle 14:50, venerdì 11 ottobre 2002, Michel Dänzer ha scritto: > > >>Will these modifications also work with older firmware or whatever makes >>the difference? > > > Oops, you're right, i haven't tried this, i will try it (downgrading the > firmware) this weekend. > Test results will follow. > > >>>The warbled text problem i signaled succedes only in the X text windows >>>as Xterm or Mozilla and so on. I think this is a driver's limitation >>>because with 1024x768x16 resolution this succedes only when the machine >>>is very stressed but with 1152x864x16 and over this succedes everytime i >>>open a window. With these high resolutions it warbles also the graphics. >> >>Sounds like bus contention and/or synchronization problems in the 2D >>acceleration code. > > > I think that what you are saying is also (or something near) the reason > why the framebuffer crashes after a vterm exchange from X . > Is it possible that X is not signalled to release its resources and go to > sleep ? > The few times that i am able to exchange vterms, X is completely killed > (also its child tasks) by the system and the Xdm task that remains alive > is not able to re-open another X task. > I can test it, could you suggest me where to put the hands :-) ? > > Regards > > Giorgio > > Post Scriptum. > In my last mail i forgotten to say that after the migration of my Linux > partitions from IDE to SCSI hdisks, a strange bug seems disappeared: > Sometimes, when connected to internet and using X, something > hanged the X task or the whole machine. Now seems solved... > (I cross my fingers... :-) ). Seems the same problem like i have. Btw: i still have problems with it, sometime it even crashes during init of the scsi disks! Sometimes later... bug is still present. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-apus-devel > |
|
From: Giorgio T. <de...@ip...> - 2002-10-12 09:58:00
|
Alle 14:50, venerd=EC 11 ottobre 2002, Michel D=E4nzer ha scritto: > Will these modifications also work with older firmware or whatever make= s > the difference? Oops, you're right, i haven't tried this, i will try it (downgrading the=20 firmware) this weekend.=20 Test results will follow. > > The warbled text problem i signaled succedes only in the X text windo= ws > > as Xterm or Mozilla and so on. I think this is a driver's limitation > > because with 1024x768x16 resolution this succedes only when the machi= ne > > is very stressed but with 1152x864x16 and over this succedes everytim= e i > > open a window. With these high resolutions it warbles also the graphi= cs. > > Sounds like bus contention and/or synchronization problems in the 2D > acceleration code. I think that what you are saying is also (or something near) the reason why the framebuffer crashes after a vterm exchange from X . Is it possible that X is not signalled to release its resources and go to= =20 sleep ? The few times that i am able to exchange vterms, X is completely killed=20 (also its child tasks) by the system and the Xdm task that remains alive is not able to re-open another X task.=20 I can test it, could you suggest me where to put the hands :-) ? Regards Giorgio Post Scriptum. In my last mail i forgotten to say that after the migration of my Linux=20 partitions from IDE to SCSI hdisks, a strange bug seems disappeared: Sometimes, when connected to internet and using X, something hanged the X task or the whole machine. Now seems solved... (I cross my fingers... :-) ). |
|
From: Michel <mi...@da...> - 2002-10-11 12:50:28
|
On Mon, 2002-10-07 at 19:32, Giorgio Terzi wrote:=20 >=20 > as i said time ago i had problems with XFree86 some still remain > but one i think i have solved: > I had a problem of bad addressing during Xdm (Kdm-Gdm) loading > that trashed all the graphics with these symptoms: background sometimes > trashed, graphics and widgets in the greetings window become invisible > but selectable. > Note that these problems was found also before the CyberstormPPC > firmware upgrading. > After firmware upgrading i have seen that there was some differences betw= een > the PCI addressing declaration in apus_pci.c & pm2fb.c files and what the= new > ROM firmware reported. > I attack my dmesg file where is possible to see this adresses difference > and some (i think) non-influent Zorro vs. PCI address space conflicts. >=20 > I have tried the modifies below and now seems that this problem is solved= : >=20 > diff -urN orig/apus_pci.c modif/apus_pci.c > --- orig/apus_pci.c Sun Oct 28 12:44:01 2001 > +++ modif/apus_pci.c Sun Sep 1 11:46:07 2002 > @@ -167,7 +167,9 @@ > DEFW(); > writel(CVPPC_FB_APERTURE_ONE, apus_hose->cfg_data + PCI_BASE_ADDRESS_1)= ; > DEFW(); > - writel(CVPPC_FB_APERTURE_TWO, apus_hose->cfg_data + PCI_BASE_ADDRESS_2)= ; > + writel(0xe0800000, apus_hose->cfg_data + PCI_BASE_ADDRESS_2); > + DEFW(); > + writel(CVPPC_FB_APERTURE_TWO, apus_hose->cfg_data + PCI_BASE_ADDRESS_3)= ; > DEFW(); > writel(CVPPC_ROM_ADDRESS, apus_hose->cfg_data + PCI_ROM_ADDRESS); > DEFW(); > diff -urN orig/pm2fb.c modif/pm2fb.c > --- orig/pm2fb.c Tue Aug 20 14:47:29 2002 > +++ modif/pm2fb.c Sun Sep 1 11:47:22 2002 > @@ -998,7 +998,8 @@ > WR32(p->pci_config, PCI_CACHE_LINE_SIZE, 0xff00); > WR32(p->pci_config, PCI_BASE_ADDRESS_0, CVPPC_REGS_REGION); > WR32(p->pci_config, PCI_BASE_ADDRESS_1, CVPPC_FB_APERTURE_ONE); > - WR32(p->pci_config, PCI_BASE_ADDRESS_2, CVPPC_FB_APERTURE_TWO); > + WR32(p->pci_config, PCI_BASE_ADDRESS_2, 0xe0800000); > + WR32(p->pci_config, PCI_BASE_ADDRESS_3, CVPPC_FB_APERTURE_TWO); > WR32(p->pci_config, PCI_ROM_ADDRESS, CVPPC_ROM_ADDRESS); > DEFW(); > WR32(p->pci_config, PCI_COMMAND, 0xef000000 | >=20 > I wish to submit these modifies if you think they have "a sense" . Will these modifications also work with older firmware or whatever makes th= e difference? > The warbled text problem i signaled succedes only in the X text windows a= s > Xterm or Mozilla and so on. I think this is a driver's limitation because= =20 > with 1024x768x16 resolution this succedes only when the machine is very=20 > stressed but with 1152x864x16 and over this succedes everytime i open a=20 > window. With these high resolutions it warbles also the graphics. Sounds like bus contention and/or synchronization problems in the 2D acceleration code. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Ken T. <ke...@we...> - 2002-10-08 18:49:33
|
On Tue, 8 Oct 2002, Rene Brothuhn wrote: > It seems that the SCSI-deadlocks has nothing todo with Buster/Zorro. So I read hay4091.txt as saying that rev 9 Buster can cause lockups and I thought I saw that there was one unfixed bug in rev 11 regarding bus arbitrtion but may have misread the document. > the only thing I can imagine what the cause of this problem is, is the > CS-PPC itself. That's what I've put it down to uptil now, some flaw in the logic that makes the PPC look like the 68000 to the motheboard. > What are the facts? The 53c770 driver causes on some machines the same > deadlocks as the 53c710. On slower drives (like ZIP/CDROM) the drivers > seems to work. On faster drives you get deadlocks. It is also curious that > the deadlocks seems only appear on SCSI. Adding to that, the sim710 driver which I've just got running for the A4091 locksup in the same way. The 53c7xx driver for the A4091 appears to work fine for the fixed address A4000T 53c710 machines. Likewise the 53c770 on the PPC card is at a fixed address but doesn't work reliably for me. Not sure what the hardware differences are between 'real' zorro plug in cards and zorro like devices on the PPC card or motherboard. > Maybe the problem has something todo with DMA and/or SCSI synchronous > mode. Because slower drives (like ZIP/CDROM) running in asynchronous mode > and don't use much DMA (because they are slow). > The 53c770 uses DMA, but as far as I look through the 53c710 drivers, they > don't use DMA. But I'm not sure. The ZIP and CDROM drives work for longer but do eventually fail in async mode, last time I mounted a ZIP drive I worked it fairly heavily for about three hours without a problem but at other times it has locked up on the initial read when mounting. Same applies to CDROMS. I've found a couple of things in the 53c7xx driver, one of them is that the bootline async negotiation flag does not get used so the testing of I've done in that mode as been futile. Another one is a bug in the abort command interrupt processing. I've talked to the author about these. The 53c7xx driver does use DMA. Over the years I've tried many things to try to get the 4091 to work, bounce buffers, much playing cache modes, making the driver less aggresive but obviously no success. Things I have to do: Verify I have a rev 11 buster - does 53c770 being on card use buster for bus arbitration ? Keep working on the sim710 driver, calming it down and adding some DMA address debug output in the hope I can see something of use in fixing the 53c770 driver. Get out my old GVP Zorro 2 SCSI card and give that a run (Western Digital chip, not ncr), I recall it being a DMA device but not sure. This might uncover something in the APUS SCSI code or prove DMA works or not. |
|
From: Rene B. <re...@we...> - 2002-10-08 14:00:16
|
On 2002.10.07 23:37 Ken Tyler wrote: > Hello, > > > > http://www.thule.no/haynie/ has lots of info about various buster / > Zorro > > > problems including one that was nerver fixed. > > > > I can't find informations about Buster/Zorro problems here. Can you > tell > > me where exactly it is? > > The site is down at the moment. Attached are two text files, I'm > assuming > I got them from the thule.no site but may have found them somewhere else. Thanks! Very interesting. It seems that the SCSI-deadlocks has nothing todo with Buster/Zorro. So the only thing I can imagine what the cause of this problem is, is the CS-PPC itself. What are the facts? The 53c770 driver causes on some machines the same deadlocks as the 53c710. On slower drives (like ZIP/CDROM) the drivers seems to work. On faster drives you get deadlocks. It is also curious that the deadlocks seems only appear on SCSI. Maybe the problem has something todo with DMA and/or SCSI synchronous mode. Because slower drives (like ZIP/CDROM) running in asynchronous mode and don't use much DMA (because they are slow). The 53c770 uses DMA, but as far as I look through the 53c710 drivers, they don't use DMA. But I'm not sure. Ciao, Renè |
|
From: Ken T. <ke...@we...> - 2002-10-07 21:38:40
|
On Mon, 7 Oct 2002, Rene Brothuhn wrote: Hello, > > http://www.thule.no/haynie/ has lots of info about various buster / Zorro > > problems including one that was nerver fixed. > > I can't find informations about Buster/Zorro problems here. Can you tell > me where exactly it is? The site is down at the moment. Attached are two text files, I'm assuming I got them from the thule.no site but may have found them somewhere else. Ken. |
107 messages has been excluded from this view by a project administrator.
