Re: What is wrong with kernels 5.X on sparc64 ?
I installed Debians latest UP (5.5.0-2-sparc64) and SMP (5.5.0-2-sparc64-smp)
kernels on my single-CPU Ultra 45
and they both work for simple "apt update && apt install some-single-package"
test.
Earlier 5.2.0-3-sparc64 kernel also works well for compiling other kernels.
Also, 5.5.0-1-sparc64 works.
Too early conclusion - compiled and installed a kernel but crashed on shutdown
(for reboot):
[ 6871.421677] Unable to handle kernel NULL pointer dereference
[ 6871.489666] tsk->{mm,active_mm}->context = 0094
[ 6871.556530] tsk->{mm,active_mm}->pgd = fff2756b8000
[ 6871.619231] \|/ \|/
[ 6871.619231] "@'/ .. \`@"
[ 6871.619231] /_| \__/ |_\
[ 6871.619231] \__U_/
[ 6871.795790] kworker/0:1(1138): Oops [#1]
[ 6871.842860] CPU: 0 PID: 1138 Comm: kworker/0:1 Tainted: GE
5.5.0-1-sparc64 #1 Debian 5.5.13-2
[ 6871.962020] Workqueue: cgroup_destroy css_killed_work_fn
[ 6872.025824] TSTATE: 008080e01600 TPC: 005d3028 TNPC:
005d302c Y: Tainted: GE
[ 6872.160601] TPC:
[ 6872.224377] g0: 009e g1: fff27638b980 g2: fff27638b980
g3: 000100864288
[ 6872.328872] g4: fff2753c8000 g5: 0021a774 g6: fff2745f4000
g7:
[ 6872.433358] o0: 00d5d598 o1: fff2762e4010 o2:
o3:
[ 6872.537843] o4: fff27638b980 o5: fff276a8 sp: fff2745f71d1
ret_pc: fff274a22280
[ 6872.646506] RPC: <0xfff274a22280>
[ 6872.690402] l0: 0001 l1: 1000 l2: 005c96c0
l3: 005c9720
[ 6872.794943] l4: 00d58800 l5: 00c29c48 l6: 00dbac00
l7: 0001
[ 6872.899429] i0: 0038 i1: fff274472000 i2: 00d5d5b0
i3: 00d5d400
[ 6873.003915] i4: fff274a22280 i5: fff27c154470 i6: fff2745f7281
i7: 00623c18
[ 6873.111709] I7:
[ 6873.174017] Call Trace:
[ 6873.204979] [00623c18] memcg_offline_kmem.part.0+0x98/0xe0
[ 6873.281892] [00626094] mem_cgroup_css_offline+0xb4/0xe0
[ 6873.355768] [004eaed8] css_killed_work_fn+0x38/0x120
[ 6873.426542] [00482c54] process_one_work+0x194/0x460
[ 6873.496229] [00483064] worker_thread+0x144/0x540
[ 6873.562782] [00488cdc] kthread+0xdc/0x120
[ 6873.622005] [00405fa4] ret_from_fork+0x1c/0x2c
[ 6873.686410] [] 0x0
[ 6873.729990] Disabling lock debugging due to kernel taint
[ 6873.795475] Caller[00623c18]: memcg_offline_kmem.part.0+0x98/0xe0
[ 6873.878743] Caller[00626094]: mem_cgroup_css_offline+0xb4/0xe0
[ 6873.958837] Caller[004eaed8]: css_killed_work_fn+0x38/0x120
[ 6874.035813] Caller[00482c54]: process_one_work+0x194/0x460
[ 6874.111726] Caller[00483064]: worker_thread+0x144/0x540
[ 6874.184407] Caller[00488cdc]: kthread+0xdc/0x120
[ 6874.249765] Caller[00405fa4]: ret_from_fork+0x1c/0x2c
[ 6874.320251] Caller[]: 0x0
[ 6874.369854] Instruction DUMP:
[ 6874.369856] ce5f
[ 6874.406890] c4584000
[ 6874.436667] c65f2008
[ 6874.466425]
[ 6874.496071] ce704000
[ 6874.525725] c470c000
[ 6874.555388] c670a008
[ 6874.584920] de77
[ 6874.614471] de772008
--
Meelis Roos
Re: What is wrong with kernels 5.X on sparc64 ?
I wrote: I restarted the kernel config bisection using 5.6.0-12706-gb032227c6293 and current gcc-9 (9.3.0 - Debian 9.3.0-10). So far I have not found a working configuration yet. I have found a configuration from previous testing that gives me a working kernel with gcc-9.3. Bisecting the configuration now - it appears I have to "make clean" before each compilation or I will get partly old kernel that behaves differently when recompiled after "make clean". From previous bisection saved configs and notes I came to a preliminary conclusion that when I turn off SMP from working configuration, I get a nonworking configuration that differs a lot (different RCU implementation chosen etc). This hypothesis still seems to hold with gcc-9 (my latest working kernel is SMP and a nonworking one is !SMP). Will keep bisecting. I installed Debians latest UP (5.5.0-2-sparc64) and SMP (5.5.0-2-sparc64-smp) kernels on my single-CPU Ultra 45 and they both work for simple "apt update && apt install some-single-package" test. Earlier 5.2.0-3-sparc64 kernel also works well for compiling other kernels. Also, 5.5.0-1-sparc64 works. -- Meelis Roos
Re: What is wrong with kernels 5.X on sparc64 ?
I started kernel configuration bisection in December but I do not remmeber the details (gcc 8 I think) so I need to redo it from start to see what exactly is the working configuration (is the one from hopkirk reproducibly working for me, first). I restarted the kernel config bisection using 5.6.0-12706-gb032227c6293 and current gcc-9 (9.3.0 - Debian 9.3.0-10). So far I have not found a working configuration yet. From previous bisection saved configs and notes I came to a preliminary conclusion that when I turn off SMP from working configuration, I get a nonworking configuration that differs a lot (different RCU implementation chosen etc). I installed Debians latest UP (5.5.0-2-sparc64) and SMP (5.5.0-2-sparc64-smp) kernels on my single-CPU Ultra 45 and they both work for simple "apt update && apt install some-single-package" test. Earlier 5.2.0-3-sparc64 kernel also works well for compiling other kernels. Will continue searching for a working config and then config bisection to find something more precise. -- Meelis Roos
Re: What is wrong with kernels 5.X on sparc64 ?
Tried 5.6+git as of today, compiled with ccc-9, on Ultra 45. Fails - here is dmesg in case it gives some hints to somebody. It fails with a oops and chain of warnings, starting with Kernel unaligned access at TPC[7fc7f0] tty_reopen+0x10/0x100 One bunch of these unaligned accesses seem to be around tty code. I started kernel configuration bisection in December but I do not remmeber the details (gcc 8 I think) so I need to redo it from start to see what exactly is the working configuration (is the one from hopkirk reproducibly working for me, first). [0.24] PROMLIB: Sun IEEE Boot Prom 'OBP 4.25.9 2007/08/23 14:13' [0.46] PROMLIB: Root node compatible: [0.000102] Linux version 5.6.0-12706-gb032227c6293 (mroos@u45) (gcc version 9.3.0 (Debian 9.3.0-10), GNU ld (GNU Binutils for Debian) 2.34) #28 Sun Apr 12 21:17:16 EEST 2020 [0.313730] printk: bootconsole [earlyprom0] enabled [0.373102] ARCH: SUN4U [0.402296] Ethernet address: 00:14:4f:c3:38:2c [0.456447] MM: PAGE_OFFSET is 0xfff0 (max_phys_bits == 42) [0.535614] MM: VMALLOC [0x0001 --> 0x000c] [0.610619] MM: VMEMMAP [0x000c --> 0x0018] [0.702127] Kernel: Using 3 locked TLB entries for main kernel image. [0.779285] Remapping the kernel... [0.779595] done. [1.134726] OF stdout device is: /ebus@1f,464000/serial@2,80 [1.202429] PROM: Built device tree with 150486 bytes of memory. [1.274437] Top of RAM: 0x27fe4e000, Total RAM: 0x7fe48000 [1.340040] Memory hole size: 8192MB [1.387923] Allocated 16384 bytes for kernel page tables. [1.452650] Zone ranges: [1.482863] Normal [mem 0x0002-0x00027fe4dfff] [1.556825] Movable zone start for each node [1.607870] Early memory node ranges [1.650582] node 0: [mem 0x0002-0x00027effdfff] [1.725588] node 0: [mem 0x00027f00-0x00027fe39fff] [1.800592] node 0: [mem 0x00027fe3e000-0x00027fe4dfff] [1.875646] Zeroed struct page in unavailable ranges: 220 pages [1.875651] Initmem setup node 0 [mem 0x0002-0x00027fe4dfff] [2.075566] Booting Linux... [2.109990] CPU CAPS: [flush,stbar,swap,muldiv,v9,ultra3,mul32,div32] [2.187074] CPU CAPS: [v8plus,vis,vis2] [2.237696] Built 1 zonelists, mobility grouping on. Total pages: 259621 [2.318962] Kernel command line: BOOT_IMAGE=/boot/vmlinux-5.6.0-12706-gb032227c6293 root=/dev/sda1 ro [2.434217] Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes, linear) [2.529630] Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes, linear) [2.622418] Sorting __ex_table... [2.662723] mem auto-init: stack:off, heap alloc:off, heap free:off [2.770435] Memory: 2057080K/2095392K available (6625K kernel code, 889K rwdata, 1680K rodata, 416K init, 321K bss, 38312K reserved, 0K cma-reserved) [2.931045] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [3.009277] ftrace: allocating 21934 entries in 43 pages [3.089607] ftrace: allocated 43 pages with 4 groups [3.155006] NR_IRQS: 2048, nr_irqs: 2048, preallocated irqs: 1 [3.225024] clocksource: stick: mask: 0x max_cycles: 0x49cd42e20, max_idle_ns: 440795202120 ns [3.344860] clocksource: mult[3200] shift[24] [3.401113] clockevent: mult[51eb852] shift[32] [3.455337] Console: colour dummy device 80x25 [3.508536] printk: console [tty0] enabled [3.557480] printk: bootconsole [earlyprom0] disabled [0.24] PROMLIB: Sun IEEE Boot Prom 'OBP 4.25.9 2007/08/23 14:13' [0.46] PROMLIB: Root node compatible: [0.000102] Linux version 5.6.0-12706-gb032227c6293 (mroos@u45) (gcc version 9.3.0 (Debian 9.3.0-10), GNU ld (GNU Binutils for Debian) 2.34) #28 Sun Apr 12 21:17:16 EEST 2020 [0.313730] printk: bootconsole [earlyprom0] enabled [0.373102] ARCH: SUN4U [0.402296] Ethernet address: 00:14:4f:c3:38:2c [0.456447] MM: PAGE_OFFSET is 0xfff0 (max_phys_bits == 42) [0.535614] MM: VMALLOC [0x0001 --> 0x000c] [0.610619] MM: VMEMMAP [0x000c --> 0x0018] [0.702127] Kernel: Using 3 locked TLB entries for main kernel image. [0.779285] Remapping the kernel... [0.779595] done. [1.134726] OF stdout device is: /ebus@1f,464000/serial@2,80 [1.202429] PROM: Built device tree with 150486 bytes of memory. [1.274437] Top of RAM: 0x27fe4e000, Total RAM: 0x7fe48000 [1.340040] Memory hole size: 8192MB [1.387923] Allocated 16384 bytes for kernel page tables. [1.452650] Zone ranges: [1.482863] Normal [mem 0x0002-0x00027fe4dfff] [1.556825] Movable zone start for each node [1.607870] Early memory node ranges [1.650582] node 0: [mem 0x0002-0x00027effdfff] [1.725588] node 0: [mem 0x00027f00-0x00027fe39fff] [
Re: What is wrong with kernels 5.X on sparc64 ?
[ 1730.742544] Caller[0056d008]: shrink_active_list+0x188/0x480 [ 1730.820323] Caller[0056d6e0]: shrink_lruvec+0x3e0/0x660 [ 1730.892875] Caller[0056dad4]: shrink_node+0x174/0x760 [ 1730.963247] Caller[0056e17c]: do_try_to_free_pages+0xbc/0x400 [ 1731.041995] Caller[0056e598]: try_to_free_pages+0xd8/0x1a0 [ 1731.117573] Caller[005a349c]: __alloc_pages_slowpath+0x35c/0xc40 [ 1731.199339] Caller[005a3f44]: __alloc_pages_nodemask+0x1c4/0x2a0 [ 1731.281088] Caller[0058b874]: __handle_mm_fault+0x654/0xac0 [ 1731.357590] Caller[0058bd90]: handle_mm_fault+0xb0/0x140 [ 1731.430920] Caller[0044cd6c]: do_sparc64_fault+0x52c/0x7c0 [ 1731.506365] Caller[00407440]: sparc64_realfault_common+0x10/0x20 [ 1731.588044] Caller[fff100ad44dc]: 0xfff100ad44dc [ 1731.653100] Instruction DUMP: [ 1731.653102] 820863ff [ 1731.689901] c658e040 [ 1731.719354] 83287003 [ 1731.748838] [ 1731.778337] 02f0fff3 [ 1731.807816] 8330b021 [ 1731.837289] 0f00357d [ 1731.866761] 820863ff [ 1731.896211] f859e398 -- Meelis Roos
Re: What is wrong with kernels 5.X on sparc64 ?
29.03.20 22:27 John Paul Adrian Glaubitz kirjutas:
Does anybody have some information or experience with this phenomenon?
I think I have seen instability issues on the one IIIi machine we have
as well as this machine is running 4.19 for that reason. Other machines
such as the T2 or later models don't show any issues.
So, I think this issue needs to be bisected and reported to the SPARC
Linux kernel mailing list [1]. I'm CC'ing Meelis Roos who has been doing
a lot of kernel regression testing on sparc64 in the past and might have
already found the problematic commit.
My test matrix is publicly available at
https://docs.google.com/spreadsheets/d/1nCMi_lQWA0q97VPh5m7zP3SDpw6NiVm6tRxQxVww7-o/
Here, my Ultra 45 has some stability problems with 5.2 and 5.3 and failure with
5.4.
The failures looked same as with Netra 240 (for some reason, 5.3 workd there
but 5.2
and 5.4 did not) - had something to do with RCU frequently. I never came to
reporting
this fully since I could not exactly pinpoint it, then I started two office
moves in
parallel and the quarantine came after that so I did not manage to set up my
testbed
in the new office yet.
Looking for some notes - see below for some other crash notes - but no
successful bisect.
However, there was a on irc (hopkirk, I think) who had a working 5.4.2 kernel
config for
his Ultra45 with gcc-8.3.0 (I only tested with gcc-9).
Also, it appears I have some sparc with me at home - Ultra 45, E420R,Fujitsu
M3000
(does not run Linux) and V445 with something broken (probably power backplane).
I might want to install Linux on E420R but do not have FC-AL disks with me.
If I get the disks, what's the state of Debian-ports installer - is it worth
trying on sparc64 now?
So I reconnected and started the Ultra 45. It boots up with 5.4 (with warnings
in dmesg)
and whatever Debian I had in December 2019. It did successful git fetch but
died soon
after that with something that ended in this below. WIll try curent kernel to
id I succeed.
[ 828.422505] Kernel unaligned access at TPC[5a6b20]
kmem_cache_alloc+0x60/0x280
[ 828.511966] Unable to handle kernel paging request in mna handler
[ 828.511968] at virtual address 91d0200591d02005
[ 828.643393] current->{active_,}mm->context = 021f
[ 828.713824] current->{active_,}mm->pgd = fff279d0
[ 828.780076] \|/ \|/
[ 828.780076] "@'/ .. \`@"
[ 828.780076] /_| \__/ |_\
[ 828.780076] \__U_/
[ 828.962220] (journald)(398): Oops [#45]
[ 829.009552] CPU: 0 PID: 398 Comm: (journald) Tainted: G D
5.4.0 #26
[ 829.103434] TSTATE: 11001600 TPC: 005a6b20 TNPC:
005a6b24 Y: 03049a33Tainted: G D
[ 829.241234] TPC:
[ 829.296086] g0: fff279cf77d0 g1: g2: fff27fda9fa8
g3: 0030
[ 829.403697] g4: fff27917c000 g5: fff1000377d8 g6: fff279cf4000
g7: 12cd
[ 829.511433] o0: fff2787c3c80 o1: 0dc0 o2: 00408001
o3: fff27fda9fb0
[ 829.619212] o4: 0bd0 o5: fff278b11000 sp: fff279cf7071
ret_pc: 005a6c10
[ 829.731189] RPC:
[ 829.787146] l0: l1: l2:
l3:
[ 829.894885] l4: l5: l6:
l7: fff100484000
[ 830.002727] i0: fff2780c1e00 i1: 0dc0 i2: 005be394
i3: 00404000
[ 830.110872] i4: fff2787c3c80 i5: 91d0200591d02005 i6: fff279cf7121
i7: 005be394
[ 830.219104] I7: <__alloc_file+0x14/0xe0>
[ 830.268042] Call Trace:
[ 830.299131] [005be394] __alloc_file+0x14/0xe0
[ 830.362645] [005be7ec] alloc_empty_file+0x4c/0xc0
[ 830.430384] [005cd430] path_openat+0x10/0x1580
[ 830.494997] [005cfbb0] do_filp_open+0x50/0xc0
[ 830.558562] [005ba164] do_sys_open+0x144/0x240
[ 830.623157] [005ba2c0] sys_openat+0x20/0x40
[ 830.684571] [00406154] linux_sparc_syscall+0x34/0x44
[ 830.755357] Caller[005be394]: __alloc_file+0x14/0xe0
[ 830.825019] Caller[005be7ec]: alloc_empty_file+0x4c/0xc0
[ 830.898870] Caller[005cd430]: path_openat+0x10/0x1580
[ 830.969623] Caller[005cfbb0]: do_filp_open+0x50/0xc0
[ 831.039277] Caller[005ba164]: do_sys_open+0x144/0x240
[ 831.109987] Caller[005ba2c0]: sys_openat+0x20/0x40
[ 831.177544] Caller[00406154]: linux_sparc_syscall+0x34/0x44
[ 831.254478] Caller[fff100303200]: 0xfff100303200
[ 831.319880] Instruction DUMP:
[ 831.319882] 02c74013
[ 831.356956] 0100
[ 831.38668
I remember seeing these "Kernel unaligned access at TPC[..." on USIII class
machines for long now and I have
mostly ignored them after reporting once but they seem to be a pattern in these
crashes now.
5.4.0-rc4:
[ 41.216971]
Re: Updated installation images for Debian Ports 2019-05-09
Hello Meelis, Perhaps of interest ... i was being hit with the qla2xxx driver panics as well on my v880. I unplugged the second FCAL loop to the backplane, and this fixed it. Perhaps this is something you could try? I have not tried on my V880 but I got similar trouble on V480. But where is the secondary loop on SB1000/E280R (having the same mainboard)? Hmm, come to think of it, there is a connector marked with double arrow, the back of mainboard but I do not think I have seen any cable that would fit there. -- Meelis Roos
Re: Updated installation images for Debian Ports 2019-05-09
Given that it works on a sun4u then I am guessing that a Sunblade 2000 should be perfect for this sort of thing. I know that I have one of those in the warehouse. However I think they need FCAL disks. Anyways I will give that a look see and also I hope serial console works out of the box. Yes, I should try it on some sun4u too. And probably bare hardware sun4v - all my sparcs run Linux natively. About Blade 1x00/2x00 and E280R: they use qla2xxx for root disks and last I tried this was broken in the kernel. It may be better now but older Symbios and newer MPT etc controllers would probably be a safer try if you have them available. -- Meelis Roos
Re: Updated installation images for Debian Ports 2019-05-09
[2] also has some further reading about this topic. Maybe you get in touch with Meelis Roos, who started a thread titled "Adding support for Fujitsu SPARC64 machines?" on the linux-sparc mailing list (see [3]) some years ago. Maybe this can be revived. [3]: https://marc.info/?l=linux-sparc=142067252101925=2 I'm actually here on this list. But no, nothing came out of my plan - because of lack of time from my side and the student going away. I still have the PP450 wired up and ready to run if power is turned on from xscf, so if there is someone else taking it on, I can offer PP450 access. M4000, PP650 and PP250 are away in storage. -- Meelis Roos
Re: Trying out debian sparc64
> > Comparing filesystem features - the news fs has 64bit and metadata_csum > > features that my working ext4 filesystems do not have. Will make more > > test to see if these are related. Recreated the filesystem manually with -O ^64bit,^metadata_csum, installed on it and silo works. So it seems one of these new options needs bootloader support too - at least in silo, have not tried grub yet. Unrelated - git seems to be not installable at the moment because of version conflict with git-man? sparc-utils seems to be missing from sparc64 - no eeprom and prtconf programs? Sending prtconf output was my first task after getting system installed, since there is no t5140 in the prtconfs repo. -- Meelis Roos (mr...@linux.ee)
Re: Trying out debian sparc64
> I agree that this is a problem, there is actually a technical reason > for that which is the fact that the bootloader (or was it the > firmware?) is choking on the size of the installer image. > > I did create some images for testing: > > > https://people.debian.org/~glaubitz/netboot/ Will try, thanks! > This is the new standard debian-installer which uses GNU screen when > installing over a serial terminal. I was sure there were hints on how > to switch between the terminals. It's an improvement over the previous > design as you couldn't switch terminals over a serial connection at > all. Yes, screen keybindings do work, this is useful. > > * Installer still tells ext4 is unsupported for silo, that should not be > > a problem for years now? Actually, I may have hit a problem with silo - silos is not fining any files, no /etc/silo.conf, no /boon/vmlinuz or any other file. Comparing filesystem features - the news fs has 64bit and metadata_csum features that my working ext4 filesystems do not have. Will make more test to see if these are related. > SILO is being phased out and replaced with GRUB anyway. The reason why > we're still defaulting to SILO and not GRUB is because not all patches > by Eric Snowberg have been merged upstream yet and are hence part of > the package. > > See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854568 Should it work on any sparc64? > > * Installer asks for mirror and there is no good information on the > > wiki. I derived host = deb.debian.org and directory = /debian-ports and > > it started downloading so seems correct. > > This is an issue with choose-mirror from debian-installer which does > not officially support Debian Ports at the moment. I added the key manually with apt-key add - and got past that step. > > So it seems the installer does not have relevant PGP key for this repo. > > > > Am I using wrong repo? Should I add some PGP key manually? Or is the > > March installer out of date with respect to current PGP keys after > > stretch was released? > > This was an issue in debian-cd and has been fixed: > > > https://.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=debian-cd/debian-cd.git;a=commit;h=b6c7df147ab61ae42d97610b78e8480cb8b81e00 No actual hostname int he URL? -- Meelis Roos (mr...@linux.ee)
Re: USB on Ultra 10
VV i tried to install an USB2.0 controller on Ultra 10 (to be able to VV connect an external USB device); but unfortunately the system does not VV boot with the USB controller inserted into a PCI slot: upon power on, VV the display switches on, but nothing is comes up, - even not the openboot. I tried a generic Opti OHCI USB 1.1 controller in my U5 (same mainboard as U10) and it worked fine. So there is some hope. -- Meelis Roos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing and KDE 3.4.2
JS yesterday I made a dist-upgrade, since then all the kde apps are always JS crashing (konsole, kopete, akregator, etc.). All the non kde apps JS (Firefox, evolution, etc.) work normally. The previous version of KDE JS 3.3.2 was really stable on my system. I did try KDE 3.4.2 on my U5 with unstable after a long time. Kwin crashed for me. So I did rm -rf .kde* .qt* and after that KE created a fresh configuration and worked fine. -- Meelis Roos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tg3 driver fails
DSM No user wants to hear a story, they want their systems to work, and DSM developers do too. I don't want to hear a story either, because all I DSM see are user's systems not working and nothing that can be done about DSM it at this time. rant There are also other kinds of people who just choose the vendors who work with opensource community and whose products do not need nonfree firmware. Personally, I have stayed away from tg3 (among other things) because the vendor and/or driver authors can't make it work hassle-free for me. It _seems_ to go against kernel and Debian policies and so causes troubles. As a user, I see nothing wrong with (for instance) standard firmware loading interface support so nonfree firmware can be supported better by distributions. /rant -- Meelis Roos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
d-i problem on sparc32 with partitions
Hi, I tried to install sarge on Sun Sparcstation 5/170 with the latest installer, debian/dists/sid/main/installer-sparc/20050317/images/sparc32/netboot/2.6/boot.img and failed. Everything went fine until I started partitioning the disk. It's a 4.3G COMPAQ ST34371W (Seagate). Previously it was partitioned like that (only sizes and names from /proc/partitions copied by hand from the screen): 4193000 sda 1855440 sda1 1855440 sda2 4190400 sda3 I don't know what disklabel it used, dmesg didn't tell anything about disklabel type. I chose to erase entire disk, then /proc/partitions showed this suspicios table: 4193000 sda 2147483647 sda3 And then I chose to use single partition and got error message telling Failed to partition the selected disk This probably happened because there are too many (primary) partitions in the partition table. I tried with 2.4.24-based netboot installer from the same directory, clearing the partition table with dd before. Still the same - it created 2T sda3 and then failed. So it seems to be not kernel-specific but rather parted. Looks like it failed in creating the whole disk partition and/or quessing wrong the disk size. -- Meelis Roos ([EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to use 200 GB Disk on Ultra10?
MJT http://www.ussg.iu.edu/hypermail/linux/kernel/0204.3/0484.html MJT MJT According to it, you should be able to use the drives in your MJT U10, but not boot from them (the kernel doesn't use the PROM MJT after the boot process and most modern kernels support LBA48). That's not so simple. First, the HDD needs to support LBA48 addressing. Any 137G+ disk trivially support it. Second, the IDE controller must support LBA48 addressing. This is more mysterious: to the best of my knowledge, any IDE controller supports LBA48 in PIO modes but most older controllers do not support LBA48 in DMA modes (the second address word confusing state automatas or something like that). Third, the driver of the specific IDE controller must support LBA48. Usually the driver supports LBA48 only when it's possible to use DMA with LBA48 (I'm not aware of any Linux driver that supports LBA48 in PIO mode only). For U5/U10 the problem lies in the IDE controller - the integrated controller does not support LBA48 in DMA mode. And that's it. Not a driver problem but a hardware limitation. Use a PCI IDE controller for the bigger disks but boot from the integrated one since ypu probably can't find a PCI IDE controller with Sparc OpenFirmware ROM that is needed for booting from this device. -- Meelis Roos
Re: Question on extended LBA (48Bit) adressing of HDD
JD FYI: I upgraded the bios of my Promise TX2 - 133 without success (what was = JD in accordance with my expectations. I had had build 14, now it's build 15).= If it was not a F-code ROM for OpenFirmware, it does not change anything since PC ROMs are not run on sparcs (obviously). -- Meelis Roos
Re: Sun Ultra Enterprise 2 2.6.x Kernel Issues
fbbbdyc 2.6.6 and 2.6.7 work, except for my Type 5 keyboard. I included type 5 fbbbdyc and input core support, and the serial chip and keyboard/mouse get fbbbdyc detected properly. The system remains accessible over SSH. Does the network work too? I have trouble with onboard NIC in UE2 in 2.6 kernels (haven't tried 2.6.8), it causes a hang. It might be my kernel config, if someone has hme network working with UE2 in SMP mode, would you please send your .config to me (or tell that stock debian config works). -- Meelis Roos
Re: RC1 - successful install on SPARCServer20 (32 bit - 2.4.26SMP)
AMAC Totally excellent dudes, RC1 rocks. It needed a bit of thinking about I have also installed RC1 successfully on SS5/70 and dual UE2/168 with 1 internal disk and enough RAM each. From netboot and net install. Works great, thanks! But the install on my Ultra 5 failed because I wanted to install on an external SCSI disk and there were no SCSI drivers on the netboot installer. Both Adaptec 7xxx and Symbios 53c8xx are quite spread even on Suns and they work fine when Linux driver is compiled so I suggest adding these drivers it any size limitations don't prevent it. -- Meelis Roos
Re: Issues with netboot for Sarge on Netra X1
KL The following packages have unmet dependencies: KL base-config: Conflicts: tasksel ( 2.00) but 1.52 is to be installed KL initrd-tools: Depends: cramfsprogs (= 1.1-4) but is it not going to be KLinstalled KL Depends: dash but it is not going to be installed KL E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify KL a solution). I got exactly the same bug on a SparcStation 5 yesterday. It seems a temporary problem, I have secceeded in installing Sarge on this same SS5 before (with earlier sarge beta installers). -- Meelis Roos
Re: Sarge on a Sparc5
umount: /initrd: Invalid argument (and hangs here) can you help us to debug this one ? After this umount, it should launch bterm and main-menu. Can you netboot with this argument init=/bin/sh and then : $ mount -t devfs /dev /dev This succeeds. $ bterm -f unifont.bgf This hangs. It also doesn't respond to ^C and ^Z (maybe it doesn't have to). -- Meelis Roos ([EMAIL PROTECTED])
Re: Sarge on a Sparc5
umount: /initrd: Invalid argument (and hangs here) And it hangs on sparc64 too (Ultra Enterprise 2 netbooted). can you help us to debug this one ? After this umount, it should launch bterm and main-menu. Can you netboot with this argument init=/bin/sh and then : $ mount -t devfs /dev /dev $ bterm -f unifont.bgf And sparc64 also hangs on running bterm. -- Meelis Roos ([EMAIL PROTECTED])
Re: Sarge on a Sparc5
$ bterm -f unifont.bgf And sparc64 also hangs on running bterm. bterm needs a frame buffer. Are you installing over a serial line? If not what video card do you have in your machines? Yes, I noticed it does not work on serial :) I tried both Sparcstation 5 and Ultra Neterprise 2 on the console, using sbus cg6 framebuffer in both cases. Have not tried it on another sparc64 with ati mach64 graphics, will do if I get time. -- Meelis Roos ([EMAIL PROTECTED])
Re: Sarge on a Sparc5
I tried out sarge and sid installers on a 70 MHz SS5 with 64M RAM and original 550M HDD and had similar problems (tried only netboot install): The entire install halted with the following lines: Setting up filesystem please wait busybox[8]: Unimplemented SPARC system call 188 busybox[9]: Unimplemented SPARC system call 188 busybox[11]: Unimplemented SPARC system call 188 busybox[12]: Unimplemented SPARC system call 188 init[10]: Unimplemented SPARC system call 188 busybox[13]: Unimplemented SPARC system call 188 These are not fatal, my working sparcs display a lot of these 188's with 2.4 kernels but still work. 2.6 kernel does not emit these messages. Needless to say I'm stuck. Is there a parameter I need to put in before boot or will this work at all on this old box? I received the following output from sarge installer 20040315: Freeing unused kernel memory: 132k freed Warning: unable to open an initial console. busybox[7]: Unimplemented SPARC system call 188 init[1]: Unimplemented SPARC system call 188 Kernel panic: Attempted to kill init! Press L1-A to return to the boot prom And from sid 20040411: Freeing unused kernel memory: 132k freed Setting up filesystem, please wait ... busybox[7]: Unimplemented SPARC system call 188 busybox[8]: Unimplemented SPARC system call 188 busybox[10]: Unimplemented SPARC system call 188 busybox[11]: Unimplemented SPARC system call 188 init[9]: Unimplemented SPARC system call 188 busybox[12]: Unimplemented SPARC system call 188 umount: /initrd: Invalid argument (and hangs here) Leaving out the noise of Unimpl..., it's the same result as on mips (R4k Indy). Seems to be a more general debian-installer problem to me. -- Meelis Roos ([EMAIL PROTECTED])
Re: Sound on Sun Blade 1000
PJ You're using a sound card which isn't going to work in a sparc64. PJ Basicly, the card only has 30-bits of address space, whereas pci has a PJ 32-bit memory address space. The sparc pci controller always assigns PJ addreses with the high bit set, so that's just not going to work. Yep. I did an experiment to get sound out of my Blade 100 in Linux: using 32-bit PCI DMA mask, not the 30-bit one. This has been working for months without any stability problems. I do not listen much music here, occassional beeps and one soundplay a week. Works for me but I don't know wheter it really should :) Index: drivers/sound/trident.c === RCS file: /vger/linux/drivers/sound/trident.c,v retrieving revision 1.50 diff -u -r1.50 trident.c --- drivers/sound/trident.c 10 Nov 2001 08:52:22 - 1.50 +++ drivers/sound/trident.c 17 Dec 2001 09:55:21 - @@ -186,7 +186,7 @@ #define TRIDENT_CARD_MAGIC 0x5072696E /* Prin */ #define TRIDENT_STATE_MAGIC0x63657373 /* cess */ -#define TRIDENT_DMA_MASK 0x3fff /* DMA buffer mask for pci_alloc_consist */ +#define TRIDENT_DMA_MASK 0x /* DMA buffer mask for pci_alloc_consist */ #define NR_HW_CH 32 -- Meelis Roos ([EMAIL PROTECTED])
Re: Binutils no longer autobuilding the cross-compiling packages...
I think he was talking about building cross-compilers on the m68k platform, not about cross-compilers to generate m68k binaries. Yes, I understood the same. I do use binutils-m68k on i686 and find it convenient but I also agree that building cross-binutils for all archs on all archs (even the slow ones) is a overkill. --- Meelis Roos ([EMAIL PROTECTED])
