* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) @ 2006-03-22 17:18 Joel Soete 2006-03-22 18:16 ` Helge Deller 0 siblings, 1 reply; 18+ messages in thread From: Joel Soete @ 2006-03-22 17:18 UTC (permalink / raw) To: deller; +Cc: grundler, parisc-linux, tsg45800 > Hi all, > > it turned out, that it was a stupid bug in the PFN calculation of the D= TLB handler routine. > It's fixed now in CVS. > The 64bit Kernel boots now, but I still have to clean up STIfb driver t= o do the right thing. > > Anyway, nice to have this fixed. > If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP option. > Great job ;-) Tested on n4k (2 way 64bit kernel) and all seems to works fine. But unfortuantely failed to boot on b2k (64bit up kernel): Soft power switch enabled, polling @ 0xfffffff0f0400804. = STI GSC/PCI core graphics driver Version 0.9a = STI PCI graphic ROM found at fffffffff4940000 (128 kB), fb at fffffffffb0= 00000 (16 MB) id 35acda16-9a02587, conforms to spec rev. 8.0c = BUG: soft lockup detected on CPU#0! = = YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI = PSW: 00001000000001000000000000001111 Not tainted = r00-03 0000000000000000 0000000000000080 000000001010a908 00000000800000= 00 r04-07 000000000000002a 00000000a8000000 0000000000000555 00000000000000= 0d r08-11 0000000000000000 0000000090dc4f6c 0000000000000001 0000000010dc51= c8 r12-15 0000000000000010 0000000000000010 0000000000000001 ffffffffffffff= ff r16-19 000000001043b328 0000000000000000 0000000000000000 00000000000000= 00 r20-23 0000000000000000 0000000000000000 0000000000000005 00000000000080= 00 r24-27 0000000000000000 0000000000008000 00000000000000cc 00000000105cbc= 40 r28-31 0000000000000000 00000000002aa800 0000000010dc5390 00000000002aa8= 00 sr0-3 0000000000000000 0000000000000000 0000000000000000 00000000000000= 00 sr4-7 0000000000000000 0000000000000000 0000000000000000 00000000000000= 00 = VZOUICununcqcqcqcqcqcrmunTDVZOUI = FPSR: 00000100000100000000100000000000 = FPER1: 24850e06 = fr00-03 0000000000000000 0000001f00000000 0000001f00000000 0000001f00000= 000 fr04-07 0000000000000000 5555555555555555 5555555555555555 5555555555555= 555 fr08-11 5555555555555555 5555555555555555 5555555555555555 5555555555555= 555 fr12-15 5555555555555555 5555555555555555 5555555555555555 5555555555555= 555 fr16-19 5555555555555555 5555555555555555 5555555555555555 5555555555555= 555 fr20-23 5555555555555555 5555555555555555 0000000000000000 0000000000000= 000 fr24-27 0000000000000000 5555555555555555 5555555555555555 5555555555555= 555 fr28-31 5555555555555555 5555555555555555 5555555555555555 5555555555555= 555 = IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000102a3cd8 00000000102a3cdc IIR: d3bd1ae8 ISR: 0000000000000000 IOR: 00000000105cbc40 = CPU: 0 CR30: 0000000010dc4000 CR31: 0000000010584000 = ORIG_R28: 00000000104bd008 = IAOQ[0]: memset+0x378/0x8e0 = IAOQ[1]: memset+0x37c/0x8e0 = RP(r2): __udivdi3+0x518/0x940 (which same 32bit kernel seems to works fine?) Thanks, Joel PS: on going to test on d380 (will advise later) =0A=0A-------------------------------------------------------=0ANOTE! My = email address is changing to ... @scarlet.be=0APlease make the necessary = changes in your address book. =0A=0A ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-22 17:18 [parisc-linux] Re: linux-2.6 deller (ioremap-changes) Joel Soete @ 2006-03-22 18:16 ` Helge Deller 2006-03-22 22:30 ` Helge Deller 0 siblings, 1 reply; 18+ messages in thread From: Helge Deller @ 2006-03-22 18:16 UTC (permalink / raw) To: Joel Soete; +Cc: parisc-linux, tsg45800 On Wednesday 22 March 2006 18:18, Joel Soete wrote: > > The 64bit Kernel boots now, but I still have to clean up STIfb driver to > > do the right thing. > > Anyway, nice to have this fixed. > > If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP option. > > But unfortuantely failed to boot on b2k (64bit up kernel): > STI GSC/PCI core graphics driver Version 0.9a > STI PCI graphic ROM found at fffffffff4940000 (128 kB), fb at fffffffffb000000 > (16 MB) > id 35acda16-9a02587, conforms to spec rev. 8.0c > BUG: soft lockup detected on CPU#0! > <crash> That's why I said I need to fix STIfb.... :-) Helge _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-22 18:16 ` Helge Deller @ 2006-03-22 22:30 ` Helge Deller 2006-03-22 23:49 ` John David Anglin 0 siblings, 1 reply; 18+ messages in thread From: Helge Deller @ 2006-03-22 22:30 UTC (permalink / raw) To: parisc-linux; +Cc: tsg45800 On Wednesday 22 March 2006 19:16, Helge Deller wrote: > On Wednesday 22 March 2006 18:18, Joel Soete wrote: > > > The 64bit Kernel boots now, but I still have to clean up STIfb driver to > > > do the right thing. > > > Anyway, nice to have this fixed. > > > If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP option. > > > > But unfortuantely failed to boot on b2k (64bit up kernel): > > STI GSC/PCI core graphics driver Version 0.9a > > STI PCI graphic ROM found at fffffffff4940000 (128 kB), fb at fffffffffb000000 > > (16 MB) > > id 35acda16-9a02587, conforms to spec rev. 8.0c > > BUG: soft lockup detected on CPU#0! > > <crash> > > That's why I said I need to fix STIfb.... :-) It's fixed now in CVS (2.6.16-pa2). Even X11 on stifb with 64bit kernel works... Helge _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-22 22:30 ` Helge Deller @ 2006-03-22 23:49 ` John David Anglin 2006-03-23 6:46 ` Helge Deller 2006-05-06 22:44 ` John David Anglin 0 siblings, 2 replies; 18+ messages in thread From: John David Anglin @ 2006-03-22 23:49 UTC (permalink / raw) To: Helge Deller; +Cc: parisc-linux, tsg45800 > > That's why I said I need to fix STIfb.... :-) > > It's fixed now in CVS (2.6.16-pa2). > Even X11 on stifb with 64bit kernel works... Did this bug also affect 32bit kernels? The reason I ask is I had to back out using 2.6.16-pa0 on my c3k. The most obvious symptoms were fsck failures on reboot, iptables error messages and unreliable behavior of gnome teminal. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-22 23:49 ` John David Anglin @ 2006-03-23 6:46 ` Helge Deller 2006-03-26 1:45 ` John David Anglin 2006-05-06 22:44 ` John David Anglin 1 sibling, 1 reply; 18+ messages in thread From: Helge Deller @ 2006-03-23 6:46 UTC (permalink / raw) To: John David Anglin; +Cc: parisc-linux On Thursday 23 March 2006 00:49, John David Anglin wrote: > > > That's why I said I need to fix STIfb.... :-) > > > > It's fixed now in CVS (2.6.16-pa2). > > Even X11 on stifb with 64bit kernel works... > > Did this bug also affect 32bit kernels? The reason I ask is I > had to back out using 2.6.16-pa0 on my c3k. The most obvious > symptoms were fsck failures on reboot, iptables error messages > and unreliable behavior of gnome teminal. The fixes I did was only related to virtually-mapped vs. physically-addressed memory regions. So I don't think I changed anything special for a 32bit kernel if you didn't set CONFIG_HPPA_IOREMAP. But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it worked fine, so I assume you shouldn't see any problems either... Helge _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-23 6:46 ` Helge Deller @ 2006-03-26 1:45 ` John David Anglin 2006-03-26 5:45 ` Grant Grundler 0 siblings, 1 reply; 18+ messages in thread From: John David Anglin @ 2006-03-26 1:45 UTC (permalink / raw) To: Helge Deller; +Cc: parisc-linux > But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it worked fine, so I assume you shouldn't see any problems either... I tried the default 2.6.16-pa5 from www.parisc-linux.org this afternoon. I still get a lot of ip_tables messages on the console which unfortunately aren't captured in any log file. I've attached the diff between 2.6.15-rc7-pa and 2.6.16-pa5 dmesg files. Is the eth0 difference significant? There's also a segv in dirmngr that occurs late in both boots. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) --- dmesg 2006-03-25 18:14:38.000000000 -0500 +++ dmesg.0 2006-03-25 18:06:12.000000000 -0500 @@ -1,4 +1,4 @@ -Linux version 2.6.15-rc7-pa1 (bame@palinux) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 Mon Jan 2 15:10:49 MST 2006 +Linux version 2.6.16-pa5 (bame@palinux) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 Thu Mar 23 20:32:12 MST 2006 FP[0] enabled: Rev 1 Model 19 The 32-bit Kernel has started... Initialized PDC Console for debugging. @@ -16,7 +16,7 @@ HighMem zone: 0 pages, LIFO batch:0 LCD display at f05d0008,f05d0000 registered Built 1 zonelists -Kernel command line: HOME=/ TERM=linux root=/dev/sdb3 console=tty0 sti=10/4/3/0 sti_font=VGA8x16 panic=180 palo_kernel=3/boot/vmlinux +Kernel command line: HOME=/ TERM=linux root=/dev/sdb3 console=tty0 sti=10/4/3/0 sti_font=VGA8x16 panic=180 palo_kernel=3/boot/vmlinux-2.6.16-pa5-c3000_defconfig PID hash table entries: 4096 (order: 12, 65536 bytes) Console: colour dummy device 160x64 Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes) @@ -35,8 +35,8 @@ 6. Allegro W2 at 0xfffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 } 7. Memory at 0xfed10200 [49] { 1, 0x0, 0x09c, 0x00009 } CPU(s): 1 x PA8700 (PCX-W2) at 875.000000 MHz -Whole cache flush 1029084 cycles, flushing 4478280 bytes 1046986 cycles -Setting cache flush threshold to 40 (1 CPUs online) +Whole cache flush 1257772 cycles, flushing 4495684 bytes 1053408 cycles +Setting cache flush threshold to 900 (1 CPUs online) SBA found Astro 2.1 at 0xfed00000 LBA version TR4.0 (0x5) found at 0xfed30000 PCI: Enabled native mode for NS87415 (pif=0x8f) @@ -48,11 +48,11 @@ SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub -unwind_init: start = 0x104064d0, end = 0x10434c00, entries = 11891 +unwind_init: start = 0x1040a400, end = 0x10439f10, entries = 12209 Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Initializing Cryptographic API io scheduler noop registered -io scheduler anticipatory registered +io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered SuperIO: Found NS87560 Legacy I/O device at 0000:00:0e.1 (IRQ 19) @@ -62,7 +62,7 @@ SuperIO: Floppy controller at 0x3f0 SuperIO: ACPI at 0x7e0 SuperIO: USB regulator enabled -PDC Stable Storage facility v0.10 +PDC Stable Storage facility v0.22 Soft power switch enabled, polling @ 0xf0400804. STI GSC/PCI core graphics driver Version 0.9a STI PCI graphic ROM found at f6000000 (64 kB), fb at f8000000 (32 MB) @@ -77,21 +77,21 @@ fb0: stifb 1280x1024-8 frame buffer device, PCI_GRAFFITIX1280, id: 2d08c0a7, mmio: 0xf8100000 stifb: 'A1262A' (id: 0x35acda30) not supported. Generic RTC Driver v1.07 -Serial: 8250/16550 driver $Revision: 1.90 $ 13 ports, IRQ sharing enabled +Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 3) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A loop: loaded (max 8 devices) Linux Tulip driver version 1.1.13 (December 15, 2004) tulip0: no phy info, aborting mtable build tulip0: MII transceiver #1 config 1000 status 782d advertising 01e1. -eth0: Digital DS21142/DS21143 Tulip rev 65 at f4008000, 00:30:6E:48:AC:EA, IRQ 17. +eth0: Digital DS21142/DS21143 Tulip rev 65 at 0001e000, 00:30:6E:48:AC:EA, IRQ 17. tulip1: EEPROM default media type Autosense. tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. tulip1: Index #1 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block. tulip1: Index #2 - Media AUI (#2) described by a 21142 Serial PHY (2) block. tulip1: MII transceiver #1 config 3100 status 7849 advertising 0101. tulip1: Advertising 01e1 on PHY 1, previously advertising 0101. -eth1: Digital DS21142/DS21143 Tulip rev 33 at f4800000, 00:60:B0:7A:02:FD, IRQ 21. +eth1: Digital DS21142/DS21143 Tulip rev 33 at 00032000, 00:60:B0:7A:02:FD, IRQ 21. Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NS87415: IDE controller at PCI slot 0000:00:0e.0 @@ -117,8 +117,8 @@ Type: Direct-Access ANSI SCSI revision: 03 target1:0:5: tagged command queuing enabled, command queue depth 16. target1:0:5: Beginning Domain Validation - target1:0:5: asynchronous. - target1:0:5: wide asynchronous. + target1:0:5: asynchronous + target1:0:5: wide asynchronous target1:0:5: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) target1:0:5: Domain Validation skipping write tests target1:0:5: Ending Domain Validation @@ -126,22 +126,30 @@ Type: Direct-Access ANSI SCSI revision: 02 target1:0:6: tagged command queuing enabled, command queue depth 16. target1:0:6: Beginning Domain Validation - target1:0:6: asynchronous. - target1:0:6: wide asynchronous. + target1:0:6: asynchronous + target1:0:6: wide asynchronous target1:0:6: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31) target1:0:6: Domain Validation skipping write tests target1:0:6: Ending Domain Validation st: Version 20050830, fixed bufsize 32768, s/g segs 256 SCSI device sda: 71132960 512-byte hdwr sectors (36420 MB) -SCSI device sda: drive cache: write through +sda: Write Protect is off +sda: Mode Sense: d3 00 10 08 +SCSI device sda: drive cache: write through w/ FUA SCSI device sda: 71132960 512-byte hdwr sectors (36420 MB) -SCSI device sda: drive cache: write through +sda: Write Protect is off +sda: Mode Sense: d3 00 10 08 +SCSI device sda: drive cache: write through w/ FUA sda: sda1 sda2 sda3 sda4 < sda5 sda6 > sd 1:0:5:0: Attached scsi disk sda SCSI device sdb: 143374738 512-byte hdwr sectors (73408 MB) -SCSI device sdb: drive cache: write through +sdb: Write Protect is off +sdb: Mode Sense: a3 00 10 08 +SCSI device sdb: drive cache: write through w/ FUA SCSI device sdb: 143374738 512-byte hdwr sectors (73408 MB) -SCSI device sdb: drive cache: write through +sdb: Write Protect is off +sdb: Mode Sense: a3 00 10 08 +SCSI device sdb: drive cache: write through w/ FUA sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 > sd 1:0:6:0: Attached scsi disk sdb sd 1:0:5:0: Attached scsi generic sg0 type 0 @@ -172,11 +180,13 @@ usb usb1: default language 0x0409 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: OHCI Host Controller -usb usb1: Manufacturer: Linux 2.6.15-rc7-pa1 ohci_hcd +usb usb1: Manufacturer: Linux 2.6.16-pa5 ohci_hcd usb usb1: SerialNumber: 0000:00:0e.2 -usb usb1: hotplug +usb usb1: uevent +usb usb1: device is self-powered +usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) -usb 1-0:1.0: hotplug +usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found @@ -187,7 +197,7 @@ hub 1-0:1.0: power on to power good time: 0ms hub 1-0:1.0: local power source is good hub 1-0:1.0: enabling power on all ports -hub 1-0:1.0: state 5 ports 3 chg 0000 evt 0000 +hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000 drivers/usb/core/inode.c: creating file '001' ohci_hcd 0000:00:0e.2: GetStatus roothub.portstatus [0] = 0x00010301 CSC LSDA PPS CCS hub 1-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s @@ -201,11 +211,13 @@ usb 1-1: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1: Product: USB Keyboard and Mouse usb 1-1: Manufacturer: SILITEK -usb 1-1: hotplug +usb 1-1: uevent +usb 1-1: device is bus-powered +usb 1-1: configuration #1 chosen from 1 choice usb 1-1: adding 1-1:1.0 (config #1, interface 0) -usb 1-1:1.0: hotplug +usb 1-1:1.0: uevent usb 1-1: adding 1-1:1.1 (config #1, interface 1) -usb 1-1:1.1: hotplug +usb 1-1:1.1: uevent drivers/usb/core/inode.c: creating file '002' ohci_hcd 0000:00:0e.2: GetStatus roothub.portstatus [1] = 0x00010301 CSC LSDA PPS CCS hub 1-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s @@ -218,11 +230,13 @@ usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2: Product: N48 usb 1-2: Manufacturer: Logitech -usb 1-2: hotplug +usb 1-2: uevent +usb 1-2: device is bus-powered +usb 1-2: configuration #1 chosen from 1 choice usb 1-2: adding 1-2:1.0 (config #1, interface 0) -usb 1-2:1.0: hotplug +usb 1-2:1.0: uevent drivers/usb/core/inode.c: creating file '003' -hub 1-0:1.0: state 5 ports 3 chg 0000 evt 0004 +hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0004 usbcore: registered new driver hiddev usbhid 1-1:1.0: usb_probe_interface usbhid 1-1:1.0: usb_probe_interface - got id @@ -239,12 +253,12 @@ usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver mice: PS/2 mouse device common for all mice -md: linear personality registered as nr 1 -md: raid0 personality registered as nr 2 -md: raid1 personality registered as nr 3 +md: linear personality registered for level -1 +md: raid0 personality registered for level 0 +md: raid1 personality registered for level 1 md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: bitmap version 4.39 -Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC). +Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC). ALSA device list: #0: Analog Devices AD1889 at 0xf400c000 irq 18 NET: Registered protocol family 2 @@ -263,17 +277,17 @@ EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 236k freed -usb 1-0:1.0: hotplug -usb 1-1: hotplug -usb 1-1:1.0: hotplug -usb 1-1:1.1: hotplug -usb 1-2: hotplug -usb 1-2:1.0: hotplug -usb usb1: hotplug +usb 1-0:1.0: uevent +usb 1-1: uevent +usb 1-1:1.0: uevent +usb 1-1:1.1: uevent +usb 1-2: uevent +usb 1-2:1.0: uevent +usb usb1: uevent Adding 265032k swap on /dev/sdb1. Priority:-1 extents:1 across:265032k Adding 263144k swap on /dev/sda1. Priority:-2 extents:1 across:263144k EXT3 FS on sdb3, internal journal -ip_conntrack version 2.4 (8192 buckets, 65536 max) - 212 bytes per conntrack +ip_conntrack version 2.4 (8192 buckets, 65536 max) - 172 bytes per conntrack kjournald starting. Commit interval 5 seconds EXT3 FS on sdb5, internal journal EXT3-fs: mounted filesystem with ordered data mode. @@ -289,4 +303,3 @@ kjournald starting. Commit interval 5 seconds EXT3 FS on sda6, internal journal EXT3-fs: mounted filesystem with ordered data mode. -ip_tables: (C) 2000-2002 Netfilter core team ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-26 1:45 ` John David Anglin @ 2006-03-26 5:45 ` Grant Grundler 2006-03-26 10:06 ` Joel Soete 0 siblings, 1 reply; 18+ messages in thread From: Grant Grundler @ 2006-03-26 5:45 UTC (permalink / raw) To: John David Anglin; +Cc: Helge Deller, parisc-linux On Sat, Mar 25, 2006 at 08:45:58PM -0500, John David Anglin wrote: > > But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it worked fine, so I assume you shouldn't see any problems either... > > I tried the default 2.6.16-pa5 from www.parisc-linux.org this afternoon. > I still get a lot of ip_tables messages on the console which unfortunately > aren't captured in any log file. I haven't paid attn to iptables changes but I probably should. In any case, that will "only" affect things like NAT or firewall. > I've attached the diff between 2.6.15-rc7-pa > and 2.6.16-pa5 dmesg files. Is the eth0 difference significant? Yes. One is using MMIO and the other is using IO port space. c3000defconfig could use MMIO too. I keep forgetting if the "GSC" Tulips (via card-mode Dino) now reliably can use MMIO too. grant ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-26 5:45 ` Grant Grundler @ 2006-03-26 10:06 ` Joel Soete 0 siblings, 0 replies; 18+ messages in thread From: Joel Soete @ 2006-03-26 10:06 UTC (permalink / raw) To: Grant Grundler; +Cc: parisc-linux Grant Grundler wrote: > On Sat, Mar 25, 2006 at 08:45:58PM -0500, John David Anglin wrote: > [...] > I keep forgetting if > the "GSC" Tulips (via card-mode Dino) now reliably can > use MMIO too. > Btw, I have such additional gsc nic on my d380: which driver should I select? Tia, Joel _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-22 23:49 ` John David Anglin 2006-03-23 6:46 ` Helge Deller @ 2006-05-06 22:44 ` John David Anglin 1 sibling, 0 replies; 18+ messages in thread From: John David Anglin @ 2006-05-06 22:44 UTC (permalink / raw) To: John David Anglin; +Cc: deller, parisc-linux, tsg45800 > Did this bug also affect 32bit kernels? The reason I ask is I > had to back out using 2.6.16-pa0 on my c3k. The most obvious > symptoms were fsck failures on reboot, iptables error messages > and unreliable behavior of gnome teminal. The fsck problem turned out to be the same as reported here: http://lists.debian.org/debian-kernel/2006/02/msg00153.html. udev was running out of memory and /dev was getting fully populated. It might be that the udev package got stuck. I removed and reinstalled it. The hack in the debian bug report also seems to work. I believe that the iptables problem can be fixed by a config update but I haven't test it. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) @ 2006-03-23 8:38 Joel Soete 2006-03-23 13:54 ` John David Anglin 0 siblings, 1 reply; 18+ messages in thread From: Joel Soete @ 2006-03-23 8:38 UTC (permalink / raw) To: deller; +Cc: dave, parisc-linux > On Thursday 23 March 2006 00:49, John David Anglin wrote: > > > > That's why I said I need to fix STIfb.... :-) > > > > > > It's fixed now in CVS (2.6.16-pa2). > > > Even X11 on stifb with 64bit kernel works... > > > > Did this bug also affect 32bit kernels? The reason I ask is I > > had to back out using 2.6.16-pa0 on my c3k. The most obvious > > symptoms were fsck failures on reboot, iptables error messages > > and unreliable behavior of gnome teminal. > > The fixes I did was only related to virtually-mapped vs. physically-addressed memory regions. > So I don't think I changed anything special for a 32bit kernel if you d= idn't set CONFIG_HPPA_IOREMAP. > > But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it= worked fine, so I assume you shouldn't see any problems either... > mmm, just about gnome (i don't yet tested iptables) since midle of last d= ec, after an apt-get dist-upgrade, sudenly many gnome based app (firefox, gftp-gtk, d4x, gnome-terminal, ...) running on a debian unstable _i386_ d= id segv (not yet fixed ;-( ). Fwiw, this seems to be an 'orphan' pb (i.e. ra= re): for me it only occures when the X server is the one of hpux-1100 and not = with another linux one (iirc X.org) (or even the solaris one :/). Otoh, that give me the opportunity to test kde brotherhood tools (even konqueror ;-) runing fine with a Ubuntu (drapper) installed actualy as a vserver on my d380. Hth, Joel =0A=0A---------------------------------------------------------------=0A= A free anti-spam and anti-virus filter on all Scarlet mailboxes=0AMore in= fo on http://www.scarlet.be/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-23 8:38 Joel Soete @ 2006-03-23 13:54 ` John David Anglin 2006-03-23 18:07 ` Helge Deller 0 siblings, 1 reply; 18+ messages in thread From: John David Anglin @ 2006-03-23 13:54 UTC (permalink / raw) To: Joel Soete; +Cc: deller, parisc-linux > > But I did booted yesterday the latest CVS 32bit Kernel on my c3k and it > worked fine, so I assume you shouldn't see any problems either... > > > mmm, just about gnome (i don't yet tested iptables) since midle of last dec, > after an apt-get dist-upgrade, sudenly many gnome based app (firefox, > gftp-gtk, d4x, gnome-terminal, ...) running on a debian unstable _i386_ did > segv (not yet fixed ;-( ). Fwiw, this seems to be an 'orphan' pb (i.e. rare): > for me it only occures when the X server is the one of hpux-1100 and not with > another linux one (iirc X.org) (or even the solaris one :/). > Otoh, that give me the opportunity to test kde brotherhood tools (even > konqueror ;-) runing fine with a Ubuntu (drapper) installed actualy as a > vserver on my d380. Generally, I prefer kde but it hasn't been installable on unstable for several months: The following packages have unmet dependencies: kde: Depends: kdeaddons but it is not going to be installed Depends: kdewebdev but it is not going to be installed Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-23 13:54 ` John David Anglin @ 2006-03-23 18:07 ` Helge Deller 0 siblings, 0 replies; 18+ messages in thread From: Helge Deller @ 2006-03-23 18:07 UTC (permalink / raw) To: John David Anglin; +Cc: parisc-linux On Thursday 23 March 2006 14:54, John David Anglin wrote: > Generally, I prefer kde but it hasn't been installable on unstable for > several months: > > The following packages have unmet dependencies: > kde: Depends: kdeaddons but it is not going to be installed > Depends: kdewebdev but it is not going to be installed Hi Dave, both packages (kdeaddons and kdewebdev) are not required packages.... If the others work it should be equally fine (specially kdelibs, kdebase, kdepim). Helge _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) @ 2006-03-23 6:17 Joel Soete 0 siblings, 0 replies; 18+ messages in thread From: Joel Soete @ 2006-03-23 6:17 UTC (permalink / raw) To: deller; +Cc: parisc-linux, tsg45800 > On Wednesday 22 March 2006 19:16, Helge Deller wrote: > > On Wednesday 22 March 2006 18:18, Joel Soete wrote: > > > > The 64bit Kernel boots now, but I still have to clean up STIfb dr= iver to > > > > do the right thing. > > > > Anyway, nice to have this fixed. > > > > If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP opt= ion. > > > > > > But unfortuantely failed to boot on b2k (64bit up kernel): > > > STI GSC/PCI core graphics driver Version 0.9a = > > > STI PCI graphic ROM found at fffffffff4940000 (128 kB), fb at fffffffffb000000 > > > (16 MB) > > > id 35acda16-9a02587, conforms to spec rev. 8.0c = > > > BUG: soft lockup detected on CPU#0! = > > > <crash> > > > > That's why I said I need to fix STIfb.... :-) > Appologies for my bad understanding of your previous advise ;-) > It's fixed now in CVS (2.6.16-pa2). > Even X11 on stifb with 64bit kernel works... > Great I will test asap. Thanks a lot, Joel=0A=0A-------------------------------------------------------=0AN= OTE! My email address is changing to ... @scarlet.be=0APlease make the ne= cessary changes in your address book. =0A=0A ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <20060307211213.3A261494013@palinux.hppa>]
[parent not found: <200603072227.38097.deller@gmx.de>]
[parent not found: <20060308073743.GA31959@colo.lackof.org>]
* [parisc-linux] Re: linux-2.6 deller (ioremap-changes) [not found] ` <20060308073743.GA31959@colo.lackof.org> @ 2006-03-12 13:26 ` Helge Deller 2006-03-13 20:34 ` Grant Grundler 2006-03-17 17:27 ` Grant Grundler 0 siblings, 2 replies; 18+ messages in thread From: Helge Deller @ 2006-03-12 13:26 UTC (permalink / raw) To: parisc-linux On Wednesday 08 March 2006 08:37, Grant Grundler wrote: > On Tue, Mar 07, 2006 at 10:27:37PM +0100, Helge Deller wrote: > > Attached is the patch. > > I still think we should try to get real ioremapping working. > > I'm no Linux-Kernel-memory-expert, but my plan was to read about it and learn. > > Currently, if I enable CONFIG_HPPA_IOREMAP the 64bit kernel crashes > > in sba_iommu.c: sba_driver_callback() after the first ioremap(). > > Maybe others here want to try as well ? > > Yes, I have. It crashed in exactly the same location. > But I don't understand the VM magic needed to make this work either. I did some more testing and analysis on this problem. (I even for the first time did some reading on Linux kernel memory management to understand all that pgd, pmd, pte stuff :-)) Here is my current analysis. Maybe someone with a better understanding might have some idea on what's going on ? drivers/parisc/sba_iommu.c does the following on my machine: void __iomem *sba_addr; sba_addr = ioremap(0xfffffffffed00000, 4096); /* 0xfffffffffed00000 is hpa of Astro BC Runway Port at 0xfffffffffed00000 [10] */ func_class = * (volatile unsigned long long *) (sba_addr + 8); Here is the important part of the bootlog: Linux version 2.6.16-rc5-pa2 (root@p100) (gcc version 3.4.3) #21 Sun Mar 12 13:43:30 CET 2006 FP[0] enabled: Rev 1 Model 19 The 64-bit Kernel has started... Found devices: 1. Astro BC Runway Port at 0xfffffffffed00000 [10] { 12, 0x0, 0x582, 0x0000b } 2. Elroy PCI Bridge at 0xfffffffffed30000 [10/0] { 13, 0x0, 0x782, 0x0000a } 3. Elroy PCI Bridge at 0xfffffffffed32000 [10/1] { 13, 0x0, 0x782, 0x0000a } 4. Elroy PCI Bridge at 0xfffffffffed38000 [10/4] { 13, 0x0, 0x782, 0x0000a } 5. Elroy PCI Bridge at 0xfffffffffed3c000 [10/6] { 13, 0x0, 0x782, 0x0000a } 6. Allegro W2 at 0xfffffffffffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 } 7. Memory at 0xfffffffffed10200 [49] { 1, 0x0, 0x09c, 0x00009 } CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz Setting cache flush threshold to 3ba6c0 (1 CPUs online) hpa start = fffffffffed00000 size=4096 <<<<<< this is the Astro BC IOREMAP: phys_addr=fffffffffed00000, offset = 0, size=4096 IOREMAP: addr = 0000000000008000 <<<<< the new vm area ( fffffffffed00000(phys) will be mapped to 0x8000(virt)) set_pte: virtual:8000 -> phys=fffffffffed00000, pte=fffffffffed00283 << here is the pte entry which ioremap() generates. The pte value seems right, and the __pgprot flags which I used were: _PAGE_PRESENT | _PAGE_RW | _PAGE_NO_CACHE; So, in my opinion, ioremap() does technically the right thing. Nevertheless, when reading the quadword from (virt) 0x8000+8 it crashes ("A Data Miss Timeout"? - see HPMC log). Below is the PIM HPMC output. Looking at the log, it seems that the pte was (mostly?) right, since the System Responder Address below is 0xfffffffffed10200. Although I don't understand why it was 0xfffffffffed10200 and not 0xfffffffffed00008 ? Any ideas ? Helge ----------------- Processor 0 HPMC Information ------------------ Timestamp = Sun Mar 12 13:12:54 GMT 2006 (20:06:03:12:13:12:54) HPMC Chassis Codes = 2cbf0 2500b 2cbf4 2cbfc General Registers 0 - 31 00-03 0000000000000000 0000000010604920 000000001027a738 000000008fc4a400 04-07 0000000010601920 0000000010576690 0000000000008000 00000000105766b8 08-11 0000000010673380 0000000000000000 000f41fa3d8dea40 00000000105673a8 12-15 000000003b9aca00 00000000ffffffff 0000000000000000 00000000f0400004 16-19 000000008fc4a400 00000000f000017c 00000000f0000174 0000000010567b50 20-23 0000000000000000 0000000000000001 000000000000093c 000000000067123c 24-27 ffffffffffffffff 0000000000000001 0000000010567b50 0000000010601920 28-31 0000000000000018 000000008fc24b30 000000008fc24890 0000000000000060 Control Registers 0 - 31 00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000 04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 08-11 0000000000000000 0000000000000000 00000000000000c0 0000000000000024 12-15 0000000000000000 0000000000000000 0000000000103000 8000000000000000 16-19 00000009653d8c30 0000000000000000 000000001027a738 000000000cd010d3 20-23 000000000035fffb 0000000040008008 000000000804000f 8000000000000000 24-27 000000000055d000 000000000055d000 00000000ffffffff 00000000ffffffff 28-31 00000000ffffffff 00000000ffffffff 000000008fc24000 00000000105b4000 Space Registers 0 - 7 00-03 00000000 00000000 00000000 00000000 04-07 00000000 00000000 00000000 00000000 IIA Space = 0x0000000000000000 IIA Offset = 0x000000001027a73c Check Type = 0x20000000 CPU State = 0x9e000004 Cache Check = 0x00000000 TLB Check = 0x00000000 Bus Check = 0x003010bb Assists Check = 0x00000000 Assist State = 0x00000000 Path Info = 0x00031800 System Responder Address = 0xfffffffffed10200 System Requestor Address = 0xfffffffffffa0000 '9000/785 B,C,J Workstation Unarchitected (per-CPU)', rev 1, 140 bytes: Check Summary = 0xcb81041000000000 Available Memory = 0x0000000080000000 CPU Diagnose Register 2 = 0x0301000000802004 CPU Status Register 0 = 0x2020c20000000000 CPU Status Register 1 = 0x8080000000000000 SADD LOG = 0x2b0a10000fc212c1 Read Short LOG = 0xc18040fffee003fd ERROR_STATUS = 0x0000000000000010 MEM_ADDR = 0x000001ff3fffffff MEM_SYND = 0x0000000000000000 MEM_ADDR_CORR = 0x000001ff3fffffff MEM_SYND_CORR = 0x0000000000000000 RUN_DATA_HIGH = 0xc1bff0fffed08040 RUN_DATA_LOW = 0xc1bff0fffed08040 RUN_CTRL = 0x0000021c00002a1c RUN_ADDR = 0xc1bff0fffed08040 System Responder Path = 0x00ffffffffffffff HPMC PIM Analysis Information: Timestamp = Sun Mar 12 13:12:54 GMT 2006 (20:06:03:12:13:12:54) '9000/785 B,C,J Workstation HPMC PIM Analysis (per-CPU)', rev 0, 1304 bytes: A Data Miss Timeout occurred while CPU 0 was requesting information. Memory/IO Controller Error Analysis Information: The Memory/IO Controller only observed the Broadcast Error. It did not log any additional information about the HPMC. Memory Error Log Information: Timestamp = Sun Mar 12 13:12:54 GMT 2006 (20:06:03:12:13:12:54) '9000/785 B,C,J Workstation Memory Error Log', rev 0, 64 bytes: No memory errors logged I/O Module Error Log Information: Timestamp = Sun Mar 12 13:12:54 GMT 2006 (20:06:03:12:13:12:54) '9000/785 B,C,J Workstation IO Error Log', rev 0, 228 bytes: Rope Word1 Word2 Word3 ------ ------------ ------------ 0 0x00000000 0x0e0cc009 0x00000000fed30048 1 0x00000000 0x1e0cc009 0x00000000fed32048 2 ---------- 0x2e0cc009 ------------------ 3 ---------- 0x3e0cc009 ------------------ 4 0x00000000 0x4e0cc009 0x00000000fed38048 5 ---------- 0x5e0cc009 ------------------ 6 0x00000000 0x6e0cc009 0x00000000fed3c048 7 ---------- 0x7e0cc009 ------------------ _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-12 13:26 ` Helge Deller @ 2006-03-13 20:34 ` Grant Grundler 2006-03-17 17:27 ` Grant Grundler 1 sibling, 0 replies; 18+ messages in thread From: Grant Grundler @ 2006-03-13 20:34 UTC (permalink / raw) To: Helge Deller; +Cc: parisc-linux On Sun, Mar 12, 2006 at 02:26:16PM +0100, Helge Deller wrote: > Here is my current analysis. > Maybe someone with a better understanding might have some idea on what's going on ? Yes - I'll take another look. You have good data below: > 1. Astro BC Runway Port at 0xfffffffffed00000 [10] { 12, 0x0, 0x582, 0x0000b } ... > hpa start = fffffffffed00000 size=4096 <<<<<< this is the Astro BC > IOREMAP: phys_addr=fffffffffed00000, offset = 0, size=4096 I think we ahould be doing an ioremap of HPA + ASTRO_IOC_OFFSET. ie 32*4k (0x20000) > IOREMAP: addr = 0000000000008000 <<<<< the new vm area ( fffffffffed00000(phys) will be mapped to 0x8000(virt)) > set_pte: virtual:8000 -> phys=fffffffffed00000, pte=fffffffffed00283 << here is the pte entry which ioremap() generates. ... > Below is the PIM HPMC output. > Looking at the log, it seems that the pte was (mostly?) right, since > the System Responder Address below is 0xfffffffffed10200. > Although I don't understand why it was 0xfffffffffed10200 and not 0xfffffffffed00008 ? We need to map the BC port to get rev info and we do that at the top of sba_driver_callback(). So I _think_ the first accesses are working. Later, sba_ioc_init() calls sba_dev->ioc[0].ioc_hpa = ioc_remap(sba_dev, ASTRO_IOC_OFFSET); That looks fine too. I just wonder why we are accessing 0xfffffffffed10200 (ioc? + ROPE0_CTL) instead of (BC HPA + 32 * SBA_FUNC_SIZE): 0xfffffffffed00000 + 32 * 4K = 0xfffffffffed20000 Maybe the offset isn't being placed into the page table correctly. (Unlikely...) > Any ideas ? I'll keep looking more later today and/or tomorrow. I want to review the HPMC data again too. thanks, grant ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-12 13:26 ` Helge Deller 2006-03-13 20:34 ` Grant Grundler @ 2006-03-17 17:27 ` Grant Grundler 2006-03-21 23:09 ` Helge Deller 1 sibling, 1 reply; 18+ messages in thread From: Grant Grundler @ 2006-03-17 17:27 UTC (permalink / raw) To: Helge Deller; +Cc: parisc-linux On Sun, Mar 12, 2006 at 02:26:16PM +0100, Helge Deller wrote: > Here is the important part of the bootlog: ... > hpa start = fffffffffed00000 size=4096 <<<<<< this is the Astro BC > IOREMAP: phys_addr=fffffffffed00000, offset = 0, size=4096 > IOREMAP: addr = 0000000000008000 <<<<< the new vm area ( fffffffffed00000(phys) will be mapped to 0x8000(virt)) > set_pte: virtual:8000 -> phys=fffffffffed00000, pte=fffffffffed00283 I'm wondering if we want all 64 bits set in the pte or if we only want to set the lower 40 (or 44 for pa8800) bits. The Astro system map only shows 40-bits. The "f_extend" might not be needed for Astro chipset if the HW will automatically alias the 32-bit address range for us. The address map doesn't indicate 4GB-256MB is aliased. But I wonder how the 32-bit OS could otherwise work - unless PA20 CPU is silently sign extending everything for us. Hrm...suggests that maybe we are doing something wrong in the asm for the 64-bit case. > Nevertheless, when reading the quadword from (virt) 0x8000+8 it crashes > ("A Data Miss Timeout"? - see HPMC log). > Although I don't understand why it was 0xfffffffffed10200 and not 0xfffffffffed00008 ? As noted before, this is a quirk in the firmware - fed10200 is the memory controller. > ----------------- Processor 0 HPMC Information ------------------ ... > MEM_ADDR = 0x000001ff3fffffff ~0UL means not valid. > RUN_ADDR = 0xc1bff0fffed08040 This was the last Runway address seen on the bus. Ditto for RUN_DATA_HIGH/LOW. Unfortunately, fffed08040 is the address of RUN_ADDR register. It suggests the memory controller never saw an error and continued recording until HPMC code reads RUN_ADDR. hth, grant ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-17 17:27 ` Grant Grundler @ 2006-03-21 23:09 ` Helge Deller 2006-03-22 3:52 ` Kyle McMartin 0 siblings, 1 reply; 18+ messages in thread From: Helge Deller @ 2006-03-21 23:09 UTC (permalink / raw) To: Grant Grundler; +Cc: parisc-linux Hi all, it turned out, that it was a stupid bug in the PFN calculation of the DTLB handler routine. It's fixed now in CVS. The 64bit Kernel boots now, but I still have to clean up STIfb driver to do the right thing. Anyway, nice to have this fixed. If STIfb is done, it's time to remove the CONFIG_HPPA_IOREMAP option. Helge On Friday 17 March 2006 18:27, Grant Grundler wrote: > On Sun, Mar 12, 2006 at 02:26:16PM +0100, Helge Deller wrote: > > Here is the important part of the bootlog: > ... > > hpa start = fffffffffed00000 size=4096 <<<<<< this is the Astro BC > > IOREMAP: phys_addr=fffffffffed00000, offset = 0, size=4096 > > IOREMAP: addr = 0000000000008000 <<<<< the new vm area ( fffffffffed00000(phys) will be mapped to 0x8000(virt)) > > set_pte: virtual:8000 -> phys=fffffffffed00000, pte=fffffffffed00283 > > I'm wondering if we want all 64 bits set in the pte or if we only want > to set the lower 40 (or 44 for pa8800) bits. The Astro system map > only shows 40-bits. > > The "f_extend" might not be needed for Astro chipset if the HW will > automatically alias the 32-bit address range for us. The address > map doesn't indicate 4GB-256MB is aliased. But I wonder how the > 32-bit OS could otherwise work - unless PA20 CPU is silently > sign extending everything for us. > > Hrm...suggests that maybe we are doing something wrong in the > asm for the 64-bit case. > > > Nevertheless, when reading the quadword from (virt) 0x8000+8 it crashes > > ("A Data Miss Timeout"? - see HPMC log). > > > Although I don't understand why it was 0xfffffffffed10200 and not 0xfffffffffed00008 ? > > As noted before, this is a quirk in the firmware - fed10200 is the memory > controller. > > > ----------------- Processor 0 HPMC Information ------------------ > ... > > MEM_ADDR = 0x000001ff3fffffff > > ~0UL means not valid. > > > RUN_ADDR = 0xc1bff0fffed08040 > > This was the last Runway address seen on the bus. > Ditto for RUN_DATA_HIGH/LOW. > > Unfortunately, fffed08040 is the address of RUN_ADDR register. > It suggests the memory controller never saw an error > and continued recording until HPMC code reads RUN_ADDR. > > hth, > grant > > _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [parisc-linux] Re: linux-2.6 deller (ioremap-changes) 2006-03-21 23:09 ` Helge Deller @ 2006-03-22 3:52 ` Kyle McMartin 0 siblings, 0 replies; 18+ messages in thread From: Kyle McMartin @ 2006-03-22 3:52 UTC (permalink / raw) To: Helge Deller; +Cc: Grant Grundler, parisc-linux On Wed, Mar 22, 2006 at 12:09:43AM +0100, Helge Deller wrote: > it turned out, that it was a stupid bug in the PFN calculation of the DTLB handler routine. > It's fixed now in CVS. > The 64bit Kernel boots now, but I still have to clean up STIfb driver to do the right thing. > Wow, way to go! ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2006-05-06 22:44 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-22 17:18 [parisc-linux] Re: linux-2.6 deller (ioremap-changes) Joel Soete
2006-03-22 18:16 ` Helge Deller
2006-03-22 22:30 ` Helge Deller
2006-03-22 23:49 ` John David Anglin
2006-03-23 6:46 ` Helge Deller
2006-03-26 1:45 ` John David Anglin
2006-03-26 5:45 ` Grant Grundler
2006-03-26 10:06 ` Joel Soete
2006-05-06 22:44 ` John David Anglin
-- strict thread matches above, loose matches on Subject: below --
2006-03-23 8:38 Joel Soete
2006-03-23 13:54 ` John David Anglin
2006-03-23 18:07 ` Helge Deller
2006-03-23 6:17 Joel Soete
[not found] <20060307211213.3A261494013@palinux.hppa>
[not found] ` <200603072227.38097.deller@gmx.de>
[not found] ` <20060308073743.GA31959@colo.lackof.org>
2006-03-12 13:26 ` Helge Deller
2006-03-13 20:34 ` Grant Grundler
2006-03-17 17:27 ` Grant Grundler
2006-03-21 23:09 ` Helge Deller
2006-03-22 3:52 ` Kyle McMartin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.