Re: framebuffer console on old ATI
Hi, John D. Baker wrote: > As you have seen, the "radeon*" and "radeondrmkmsfb*" drivers do not > attach on "r100" class devices. They have been explicitly excluded > because early in the DRMKMS integration in NetBSD, they exhibited the > "(almost) black-on-black" video problem described in: I remember seeing that issue.. long time ago, but don't remember on which OS and hardware combination. However, i checked a little better. ATI Technologies Radeon Mobility M7 LW (rev. 0x00) would be an RS250 chip, so a little bit newer. Does the same issue apply? or is it "blacklisted" for any other reason? Since I am endeavouring in compiling a kernel, I might try enabling it, if you tell me how. Just as a test, maybe magic happens. > > http://mail-index.netbsd.org/current-users/2015/02/20/msg026732 > > and later in the following PR: > > kern/49744: console is blank drm2/radeon > > The suggestion for "radeonfb*" is interesting. I see it's in the "ALL" > kernel, but not in "GENERIC" (not even as a commented-out device), so > you'd have to compile a custom kernel with it added to the config. That's what I wrote, I didn't see it, copying config from GENERIC. I also tried to compare with OpenBSD on another Laptop where framebwuffer runs wonderfully. It uses radeondrm0. I don't know how this in OpenBSD speak this compares to NetBSD. However, it detects a Mobility M9, which corresponds to RV250, which is newer... too much marketing speak there. RV200 appers to be just a shrink of RV100, a budget version of R100. But found no wiki about RS250. According to [1] it is just another Rage 6 variant, something for mobile. Riccardo [1] https://www.techpowerup.com/gpu-specs/ati-rs250.g384
Re: framebuffer console on old ATI
As you have seen, the "radeon*" and "radeondrmkmsfb*" drivers do not attach on "r100" class devices. They have been explicitly excluded because early in the DRMKMS integration in NetBSD, they exhibited the "(almost) black-on-black" video problem described in: http://mail-index.netbsd.org/current-users/2015/02/20/msg026732 and later in the following PR: kern/49744: console is blank drm2/radeon The suggestion for "radeonfb*" is interesting. I see it's in the "ALL" kernel, but not in "GENERIC" (not even as a commented-out device), so you'd have to compile a custom kernel with it added to the config. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Intel Wireless fatal error
Hi, Martin Husemann wrote: > The message is bogus, it has nothing to do with autoconfiguration. Misleading.. I was wondering what autoconfiguration had to be done after everything was connected. > > "Fatal error" is a bit in the interrupt cause register of the intel > chipset. The driver can not do anything about it and resets the device > (simmilar to a "ifconfig iwi0 down). This is not a good error handling > strategy, as you have noticed - and it is also done very wrong in the > iwi_softintr handler. Not very good and it explains aslo why, if done quickly enough, ifconfig up restores network connectivity and even open connection. Clearly, if time passes, dhcp lease might expire, connections drop, etc. > The driver should clear the interrupt, schedule a reset and ignore all > other activity untill the reset has happened. Of course the reset should > include bringing up the device to full working state again. I wonder which interrupt here happens that requires a rest - these disconnects happen also with a quite idle system. I had no X11 running and just network up and telnet in sometimes. > > However, this is obviously not easy to test and debug, as you will have to > be in a setup where this happens often enough (like your's). Let's try I wonder if 10 increased the frequency of drops or today is an unlucky day! > If you have patience and would be able to help with this: compile your > kernel with "options IWI_DEBUG" and see if that enables enough login to > give us a hint about the cause. If that is not enough you would need to > raise iwi_debug to more than the default level of 4, but that would > spam your log with every received packet. I will! The system should be fast enough. I just found that syssrc.tgz doesn't provide builds.h and one needs whole src.tgz to get it.. a little stupid. And also share. Building now will report back once done / rebooted. > Please file a PR and lets collect data there. Done. kern/58232 Riccardo
Re: framebuffer console on old ATI
Hi Michael, Michael wrote: > > Yeah, I fixed a few problems there, xrender support was broken for r1xx> > Sun's xvr-100 card is a rebadged rv100... Wonderful... eager to test. >> How do I enable radeonfb? Can I do it through configurations or do I >> need to compile my own kernel to try? > > radeonfb* at pci? Do you mean I need to compile and enable it? Since Martin is asking a debug kernel... I think I will try both then. However, I see no radeonfb* in kernel config: In the DRI legacy drivers: #radeondrm* at drm? # ATI Radeon DRM driver and then: radeon* at pci? dev ? function ? radeondrmkmsfb* at radeonfbbus? > > It's not a DRM driver, just an accelerated framebuffer console thing. > If you have an iBook you probably used it. Good to know. Yes, I have an iBook... and there I have strange issues... will ask about that separately. It is a very young 10.0 install and I am giving priority to getting all my Intel machines updated. I am comparing how the T41 behaves, which has a more modern Radeon card. There I get a framebuffer out of the box! and without any font issue either. However, I think at the end drm is enabled there, not radeonfb. [ 1.044664] radeon0 at pci1 dev 0 function 0: ATI Technologies Radeon Mobility M300 (M22) 5460 (rev. 0x00) [ 1.044664] radeon0: autoconfiguration error: unable to reserve VGA registers for i386 radeondrmkms hack [ 5.424688] radeon0: VRAM: 128M 0xC000 - 0xC7FF (64M used) [ 5.424688] radeon0: GTT: 512M 0xA000 - 0xBFFF [ 5.424688] [drm] radeon: 64M of VRAM memory ready [ 5.424688] [drm] radeon: 512M of GTT memory ready. [ 5.424688] [drm] radeon: 1 quad pipes, 1 Z pipes initialized [ 5.424688] radeon0: WB enabled [ 5.424688] radeon0: fence driver on ring 0 use gpu addr 0xa000 and cpu addr 0x0xdc697000 [ 5.424688] radeon0: radeon: MSI limited to 32-bit [ 5.424688] radeon0: radeon: using MSI. [ 5.424688] radeon0: interrupting at msi0 vec 0 (radeon0) [ 5.424688] [drm] radeon: irq initialized. [ 5.473861] [drm] radeon: ring at 0xA0001000 [ 5.513890] radeondrmkmsfb0 at radeon0 [ 5.513890] [drm] Initialized radeon 2.50.0 20080528 for radeon0 on minor 0 [ 5.513890] radeondrmkmsfb0: framebuffer at 0xc00c, size 1400x1050, depth 32, stride 5632 [ 5.603954] wsdisplay0 at radeondrmkmsfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 This is coherent to the generic kernel config I see. Riccardo
Re: Intel Wireless fatal error
El mar, 7 may 2024 a las 11:13, Martin Husemann () escribió: > > On Tue, May 07, 2024 at 08:16:18AM +, Riccardo Mottola wrote: > > [ 3574.054462] iwi0: autoconfiguration error: fatal error > > The message is bogus, it has nothing to do with autoconfiguration. > > "Fatal error" is a bit in the interrupt cause register of the intel > chipset. The driver can not do anything about it and resets the device > (simmilar to a "ifconfig iwi0 down). This is not a good error handling > strategy, as you have noticed - and it is also done very wrong in the > iwi_softintr handler. > > The driver should clear the interrupt, schedule a reset and ignore all > other activity untill the reset has happened. Of course the reset should > include bringing up the device to full working state again. > > However, this is obviously not easy to test and debug, as you will have to > be in a setup where this happens often enough (like your's). > If you have patience and would be able to help with this: compile your > kernel with "options IWI_DEBUG" and see if that enables enough login to > give us a hint about the cause. If that is not enough you would need to > raise iwi_debug to more than the default level of 4, but that would > spam your log with every received packet. > > Please file a PR and lets collect data there. > > Martin I remember such messages in my old Compal Electronics laptop i386 machine with iwi0 several months before NetBSD 10 release, at the very early moments after installing. I did not dig into that cause I ended using the more trusty ethernet, but it was very frustrating. If you think I can help with that I can compile the kernel with IWI_DEBUG as said before. It is a computer that I do not use regulary so plenty of space to do experiments. Regards. Ramiro.
Re: Intel Wireless fatal error
On Tue, May 07, 2024 at 08:16:18AM +, Riccardo Mottola wrote: > [ 3574.054462] iwi0: autoconfiguration error: fatal error The message is bogus, it has nothing to do with autoconfiguration. "Fatal error" is a bit in the interrupt cause register of the intel chipset. The driver can not do anything about it and resets the device (simmilar to a "ifconfig iwi0 down). This is not a good error handling strategy, as you have noticed - and it is also done very wrong in the iwi_softintr handler. The driver should clear the interrupt, schedule a reset and ignore all other activity untill the reset has happened. Of course the reset should include bringing up the device to full working state again. However, this is obviously not easy to test and debug, as you will have to be in a setup where this happens often enough (like your's). If you have patience and would be able to help with this: compile your kernel with "options IWI_DEBUG" and see if that enables enough login to give us a hint about the cause. If that is not enough you would need to raise iwi_debug to more than the default level of 4, but that would spam your log with every received packet. Please file a PR and lets collect data there. Martin
Re: framebuffer console on old ATI
Hello, On Tue, 7 May 2024 08:19:33 + Riccardo Mottola wrote: > > Radeonfb should Just Work(tm) - it's used mainly on macppc and sparc64 > > but I'm pretty sure it's been run on at least some little endian hw > > before. > > according to radeon manpage, mine would have an R100, the earliest > supported on X11. Yeah, I fixed a few problems there, xrender support was broken for r1xx. Sun's xvr-100 card is a rebadged rv100... > How do I enable radeonfb? Can I do it through configurations or do I > need to compile my own kernel to try? radeonfb* at pci? > drm did not configure, dmesg says. It's not a DRM driver, just an accelerated framebuffer console thing. If you have an iBook you probably used it. have fun Michael
Re: i386 - 10.0 gecko browsers
According to the latest bulk build data (https://releng.netbsd.org/bulktracker/build/724/www/), Firefox 123 failed to build, Firefox 115 also failed to build but Firefox 102 was OK. So in principle, there should be a firefox102 package. The firefox115 and firefox error is the same: /pbulk/work/www/firefox115/work/build/dist/include/js/Utility.h:482:20: error: static assertion failed: over-aligned type is not supported by JS_DECLARE_NEW_METHODS 482 | alignof(T) <= alignof(max_align_t), \ | ~~~^~~ /pbulk/work/www/firefox115/work/firefox-115.10.0/js/src/vm/MallocProvider.h:234:3: note: in expansion of macro 'JS_DECLARE_NEW_METHODS' 234 | JS_DECLARE_NEW_METHODS(new_, pod_malloc, MOZ_ALWAYS_INLINE) | ^~ For Seamonkey, there is also a failed assertion in the build log: In file included from /pbulk/work/www/seamonkey/work/build/ipc/chromium/Unified_cpp_ipc_chromium0.cpp:110: /pbulk/work/www/seamonkey/work/seamonkey-2.53.16/ipc/chromium/src/base/message_pump_libevent.cc: At global scope: /pbulk/work/www/seamonkey/work/seamonkey-2.53.16/ipc/chromium/src/base/message_pump_libevent.cc:31:40: error: static assertion failed: bad EVENT__SIZEOF_TIME_T 31 | static_assert(EVENT__SIZEOF_##TYPE == sizeof(type), \ /pbulk/work/www/seamonkey/work/seamonkey-2.53.16/ipc/chromium/src/base/message_pump_libevent.cc:43:1: note: in expansion of macro 'CHECK_EVENT_SIZEOF' 43 | CHECK_EVENT_SIZEOF(TIME_T,time_t); | ^~ I don't know how to fix these, but maybe firefox102 works for you? -- Benny On Tue, May 7, 2024 at 1:14 AM Riccardo Mottola wrote: > > Hi, > > no firefox and seamonkey as binbary packages for pkgin? > > Is there any failure reason? At least seamonkey sure runs on 32bit and > on Linux Firefox does too... > > Riccardo -- Benny
Re: framebuffer console on old ATI
Hi Michael, Michael wrote: > Radeonfb should Just Work(tm) - it's used mainly on macppc and sparc64 > but I'm pretty sure it's been run on at least some little endian hw > before. according to radeon manpage, mine would have an R100, the earliest supported on X11. How do I enable radeonfb? Can I do it through configurations or do I need to compile my own kernel to try? drm did not configure, dmesg says. Riccardo
Re: Intel Wireless fatal error
Hi, Riccardo Mottola wrote: > dmesg | grep iwi0 > [ 1.005536] iwi0 at pci2 dev 2 function 0: Intel PRO/Wireless LAN > 2200BG Mini-PCI Adapter (rev. 0x05) > [ 1.005536] iwi0: interrupting at irq 11 > [ 1.005536] iwi0: 802.11 address 00:16:6f:0c:0f:59 > [ 3574.054462] iwi0: autoconfiguration error: fatal error > > what autoconfiguration failed after it was running for a while? if those > are directly seconds it would be after 1h. just a little after writing this mail, the network disconnected again. So it lasted like 30 minutes at most :( Again another fatal error. [ 1.005536] iwi0 at pci2 dev 2 function 0: Intel PRO/Wireless LAN 2200BG Mini-PCI Adapter (rev. 0x05) [ 1.005536] iwi0: interrupting at irq 11 [ 1.005536] iwi0: 802.11 address 00:16:6f:0c:0f:59 [ 3574.054462] iwi0: autoconfiguration error: fatal error [ 31534.294058] iwi0: autoconfiguration error: fatal error This connection is stable, the router is literally 2 meters away in the same room, actually a small repeating access point that delivers WEB instead of WPA. For easy connection purposes so wpa_config is not needed while hacking+ Ifconfig shows that the ssid and key were still fine. Just as I write this.. it disconnected again ! Even if all parameters according to ifconfig look fine, including IP, reissuing dhcpcd is not enough! But "ifconfig iwi0 up" after a couple of attempts. [ 3574.054462] iwi0: autoconfiguration error: fatal error [ 31534.294058] iwi0: autoconfiguration error: fatal error [ 32554.279739] iwi0: autoconfiguration error: fatal error [ 33274.150790] iwi0: autoconfiguration error: fatal error Riccardo
Intel Wireless fatal error
Hi, I upgraded my trusty Thinkpad to T30 to 10.0 and now most rough edges have been sorted out. Yesterday I connected it via WiFi, connected remotely to it, then went to bed. Today I see the connection dropped and a green message on the console. Ifconfig says network down. dmesg | grep iwi0 [ 1.005536] iwi0 at pci2 dev 2 function 0: Intel PRO/Wireless LAN 2200BG Mini-PCI Adapter (rev. 0x05) [ 1.005536] iwi0: interrupting at irq 11 [ 1.005536] iwi0: 802.11 address 00:16:6f:0c:0f:59 [ 3574.054462] iwi0: autoconfiguration error: fatal error what autoconfiguration failed after it was running for a while? if those are directly seconds it would be after 1h. This issue happened on 9.3 too, sometimes - but I never checked console/dmesg and related things. Riccardo
