***Server sets mode: +nt
<almuhs>I'm checking the videocard of my R60e, and this have the same chipset than T60. Some months ago, I got to start Xfce in this, using Debian GNU/Hurd 2017. But now It shows the same error than T60. Can be this an error in any upgrade? <youpi>it could be an issue with the vesa driver finding the VBE <damo22>almuhs: drm needs kernel drivers, so we probably want to use rump for that <damo22>use the netbsd implementation of graphics drivers? <almuhs>I didn't installed any special driver, only the defaults <damo22>there is no driver for intel gfx in hurd <almuhs>yes, but in other times, with R60e, I got to run Xorg anyway <damo22>yeah because of VESA implementation which uses bios extensions <almuhs>so I researching about the differences between R60e and T60 <almuhs>R60 and T60 can have different BIOS chipset, It's true <damo22>almuhs: check your cmos settings, maybe there is a legacy video option <almuhs>R60e has Display configured as "Analog(VGA)" <youpi>(FWIW, starting Xorg with the vesa driver seems to be working inside qemu, so it doesn't seem like a general issue with xorg's vesa driver accessing the VBE) <damo22>hmm, maybe someone should copy qemu's implementation of VBE and put it in coreboot <almuhs>in Lenovo BIOS doesn't appears any option about VESA <swivel>doesn't Xorg give you some useful logging when it fails to start? I've little experience with hurd, but on linux Xorg logs are indispensible when troubleshooting this stuff <youpi>ah, sorry, I didn't know Almudena is a female name :) will try to remember <almuhs>in my docs, I have notes about R60e required many attempts to run Xorg. But now I don't get It <youpi>almuhs: just to make sure, are you booting in legacy or UEFI mode? <youpi>that might make a difference in enabling VBE <almuhs>R6oe and T60 are 2006 models. These doesn't have UEFI ;) <youpi>(bios manufacturers tend to avoid exposing too many options to users, VBE is and oldie that they'd probably want to hide as much as possible) <youpi>you could also try to run a Linux system without the intel or fbdev xorg driver, only the vesa driver <almuhs>I tried It yesterday, with Debian 10. In this T60, Debian GNU/Linux with VESA didn't detected screen <youpi>so it'd not be a hurd-specific issue <almuhs>despited of, using fbdev driver, I got to run Xorg <youpi>yes but that's using the fb drivers inside the Linux kernel <almuhs>by I don't know how I got to run Xorg some months ago, with Debian GNU/Hurd 2017 <almuhs>i have documented that runs Xorg was a difficult task, and required many attempts, but I don't remember how exactly I got this <almuhs>(i have a T60 and R60e with same processor (Intel T2400) and graphics (945GM/GMS/GME) ) <almuhs>i have another T60 wide screen, in which I got to run Xorg easier than R60e some months ago. I can add this to the test ;) <almuhs>damo22: btw, the "halt" command doesn't shutdown properly in Thinkpad *60 machines. It keeps the machine like hibernation <almuhs>T60 widescreen also has the same graphics chipset. Installing xorg... <almuhs>fuck... more dependencies conflicts <almuhs>i have to continue tomorrow. the update has caused a serious dependency problems with glibc <almuhs>seriosly, we need more Debian GNU/Hurd maintainers. The repository conflicts are more than common <damo22>yeah halt is broken because we need full ACPI parser <damo22>ive cleaned up that irq patch, but im not sure how to handle vm_allocate_contiguous, should it be an RPC on the mem device? <youpi>damo22: no, making it a variant of vm_allocate() should be fine <youpi>it's really down to the kernel, at that point <janneke>my hurd sees hd0s1, the linux partition (start ext2fs: ext2fs: device:hd0s1: panic: get_hypermetadata: could not mount because of unsupported optional features (0x2c0)) <janneke>but it does not see hd0s2: start ext2fs: ext2fs: device:2:hd0s2: No such device or address <janneke>i'm going to re-install and move ext4+gnu/linux to sda2 and ext2+gnu/hurd to sda1 and see what happens <janneke>sadly, the interweb say that the hurd has a 2GiB partition size (something that might have been true ~20y ago) but i cannot find much information on current limitations <youpi>the wiki has the latest information <janneke>that's indeed my problem then, the ssd is 160GB <youpi>(remember to use -o hurd when running mke2fs from linux) <youpi>160GiB disk size is not a problem per se <youpi>as long as you don't put data beyond the 128GiB limit <janneke>right, i had gnu/linux on 0-140GB and hurd from 140GB onwards <youpi>(for almuhs: the dependency/conflict problems are not a question of debian hurd "maintainers", but a question of people investigating the build failures, there is no need for any particular status to be able to contribute to this. Just investigate, find a fix, submit it upstream, and once accept it backport to debian) <youpi>once a fix is available, it's extremely easy for me to build&upload it to unreleased while waiting for the main debian archive to get it <youpi>the 99% time part is before build&upload <youpi>there's also currently a bsdmainutils dependency fuck-up, that's for all archs, not just hurd <youpi>and as a reminder, when upgrading, better use first apt-get upgrade, and only then apt-get dist-upgrade <almuhs>youpi: thanks by the info. (I read it in the log). But I need to know how to create a deb package, and how to upload it to backport <youpi>really, providing a patch is the 99% part of the time <youpi>there's one thing you need to know: building a package. That's as simple as apt-get build-dep thepackage and dpkg-buildpackage <youpi>(well, "apt-get source thepackage" too, of course) <almuhs>and, if i find an error in the dependencies required for this package. how can i edit this dependency in package configuration? <azeem>dependencies are in debian/control <gnu_srs>youpi: Regarding libdrm there is already a patch available, see #909436. But that patch is similar to the kFreeBSD build, i.e. no kernel support for drm :( <youpi>as already explained, better forward to upstream <almuhs>there are many packages that is missing. By example, there is "libreoffice-common", but not libreoffice. Can I build this packages from sources? <youpi>gnu_srs: it seems the patch needs to be refresh. While skimming over it, I saw at least one bug: DRM_IOCTL_NR shouldn't be n & 0xff, but n & 0x7f. See glibc/sysdeps/mach/hurd/bits/ioctls.h's explanation about how the ioctl request is encoded, the number is 7bits only <youpi>almuhs: there are not more than 30% packages missing, really <youpi>libreoffice is a terrible beast, you can't expect it to be buildable :) <youpi>the -common part is available only because it's an arch:all package <almuhs>i've seen similar problems with golang packages <youpi>there are some build failures in golang packages <youpi>that'd need to be investigated <youpi>but probably only after glibc 2.31 is uploaded, since it will fix a few things <youpi>build issues, need to be investigated <youpi>you know, if you go looking at bleeding edge, you'll bleed for sure <youpi>for openjdk, the concern is also to establish a way to get things accepted by Oracle <youpi>we e.g. added siginfo support for openjdk, but openjdk continued growing in non-portable ways <youpi>so it'd be significant work to port it <almuhs>by example, gentoo use icedtea to avoid openjdk compile problems <youpi>haven't looked at it, but it seems abandoned ? <youpi>I mean, it's only supporting java 6 or 7, right? <almuhs>i think icedtea is simply a fully free compilation of openjdk sources, or any similar thong <youpi>in debian there isn't an icedtea package any more, but that could be revived <almuhs>in gentoo is very common. maybe i can find its ebuild <youpi>I'm just warning that again it's quite a beast <youpi>to make it ported to non-linux <youpi>so java8 yes, better than what we currently have (old java5 from ecj) <youpi>but I'm still wondering how alive that project is <youpi>thus whether it's better to spend time on it rather than on openjdk <youpi>(since openjdk *is* buildable as it is on Debian, and people do spend time on making sure that it is) <almuhs>gentoo doesn't includes pre-compiled binaries by default, so the only option offered is icedtea <almuhs>the ebuild only includes the steps to download the sources and compile them <almuhs>(the download and compilation is automatically done by portage, of course) <azeem>Debian provides pre-compiled binaries, but they are all built by Debian <almuhs>yes, i speak about the possibility of explore the Gentoo work to port icedtea to Debian GNU/hurd <almuhs>the dependencies list and the compilation process, mainly <azeem>it's a bit unclear from the two links above what exactly is the Hurd porting <youpi>almuhs: the questions of porting icedtea/openjdk are not about dependencies etc. but actual .c code <youpi>the dependencies etc. are already resolved by the existing debian packaging <youpi>making an icedtea package on debian could indeed take the work from gentoo <youpi>but in the end you'll be faced with the same difficult part: actually porting the .c code <youpi>note that as I mentioned above debian used to have icedtea packaged, that can be used for a way simpler start <youpi>but again, it's really a beast, I'd rather recommend starting with smaller projects <youpi>otherwise you'd just manage not to finish anything <almuhs>now I'm also working in smp, anyway <almuhs>but i'm also using my thinkpad laptops to test Hurd over real hardware <almuhs>and test possible common applications <almuhs>yes, but the first steps about detection, enumeration, enabling... are good defined in the intel manuals <youpi>ok but that's only the tip of the smp question <almuhs>now i'm refactoring all these work from the work i did the last year <almuhs>yes, the concurrency problems can be many complex. But the cpus enabling and configuration is a basic step <almuhs>i'm refactoring to prevent errors from global variables access and ease the debugging <almuhs>i will try to send little patches for each basic step <almuhs>damo22 are contributing in ioapic and lapic timer <almuhs>(i try to avoid the i/o configurations, these are very complex for me) <almuhs>the detection and enumeration step is almost ready. It works properly, but i'm working in a good code organization. the latest step was add a new file to separate my arch-dependent code and the general mach calls (to find current processor, by example) <almuhs>mmm... my T60 freeze during hurd package unpacking ***DNS is now known as snd
*janneke booted the hurd on real iron (for the first time since decades) <almuhs>janneke: what machine are you using for Hurd? <janneke>installed via guix system reconfigure <almuhs>install nano, vim, emacs, git... <janneke>now i'm wondering what command to run that shows i'm actually on real iron <janneke>almuhs: installing stuff won't work yet <janneke>gotta do it with what's installed through guix system reconfigure :-) <janneke>so...gotta add pciutils in the next round <janneke>i did install some stuff, like gcc, gdb, git <youpi>janneke: you can look at the dmesg to see the disk probing for instance <youpi>well, dmesg doesn't actually work, I meant the kernel logs <youpi>which depending on how your box works, will get into /var/log/dmesg, /var/log/kern.log <youpi>or is waiting for your cat /dev/klog *janneke looks at /var/log/messages <almuhs>youpi: after reinstall and upgrade my T60 widescreen, I can confirm that the Xorg problem appeared in any update <almuhs>in this T60 widescreen I got to run Xorg with Debian GNU/Hurd 2017. But now I can't <youpi>then the usual stuff: either try to upgrade progressively to see what package upgrade breaks it, or put printfs etc. in the vesa driver to see where it breaks <youpi>normally the only packages which are involved are the hurd, libpciaccess, xserver-xorg-core, and xserver-xorg-video-vesa <youpi>possibly it's the libpciaccess through the pci-arbiter that doesn't work with your VBE <almuhs>libpciaccess was the cause of the network freezing problem in 2019 release <janneke>hmm, "who" writes /var/log/dmesg on the Hurd (i see it in the debian vm; we don't have it yet on guix) *janneke goes to read the faq <almuhs>i need the snapshot repository of 2017 release <youpi>janneke: usually that'd be rsyslog & such <janneke>almuhs: hmm: lspci: could not open file `/servers/bus/pci' <almuhs>janneke; execute lspci with root permissions *janneke mounts /hurd/pci-arbiter <janneke>oh, i don't have networking yet -- guix hardcodes that for the qemu VM <almuhs>youpi: with 2017's libpciaccess0, Xorg works <youpi>I'd say put printfs in the vesa driver calls to libpciaccess then <almuhs>i don't know where is vesa driver <almuhs>and i don't know how to patch this code <youpi>and then you'll know the package that provides the driver file showing up in the Xorg log <youpi>then apt-get source to get the source code <youpi>apt-get build-dep to get the build dependencies <youpi>then add printfs, then dpkg-buildpackage <youpi>there's nothing really difficult here <youpi>gnu_srs: I don't remember why you needed setsockopt(SO_SNDBUF), but I finished your patch, and it's now uploaded in debian <almuhs>vesa.c has more than 1000 lines... <youpi>that's small by most software <youpi>the thing is: you *never* need to read it all <youpi>use your editor to find references to libpciaccess <youpi>really, never think "omg this is so large" <youpi>we have software that have millions of lines of code <youpi>but you can enter it, you just need to grep what you are looking for <youpi>and you'll be able to work in it <youpi>that's how everybody is doing <almuhs>#if defined(XSERVER_LIBPCIACCESS) && !defined(HAVE_ISA) <almuhs>static Bool VESAProbe(DriverPtr drv, int flags); <youpi>nobody knows by heart anything beyonds thousands of lines <youpi>I don't know either, but grep does know <youpi>and thus under what condition <youpi>really, you need to take the habit of finding answers with grep etc. <youpi>so you're able to dive by yourself <almuhs>HAVE_ISA is not set in this file <almuhs>HAVE_ISA must be defined by the compiler or some similar <almuhs>grep doesn't shows any #define HAVE_ISA <youpi>it does show a line that defines it <almuhs>configure.ac:71: [AC_DEFINE(HAVE_ISA, 1, [Have ISA support])], <youpi>then check in the build log whether it gets enabled or not <youpi>whether it used to be enabled or not, and nowadays how it is <youpi>possibly that's not the actual problem, but it's worth checking it <youpi>again, no guess work, just checking what seems odd <almuhs>AC_CHECK_DECL(xf86ConfigIsaEntity, <almuhs> [AC_DEFINE(HAVE_ISA, 1, [Have ISA support])], <almuhs>this block is not hide under a if <youpi>look in the autoconf documentation to know about that macro <youpi>it's extremely common, leanr about it <almuhs> AC_CHECK_DECL (symbol, [action-if-found], [action-if-not-found], [includes = ‘AC_INCLUDES_DEFAULT’]) <almuhs>then I have to find (xf86ConfigIsaEntity <youpi>so check in the buid logs if the symbol is found, and whether it *used* to be found <almuhs>checking whether xf86ConfigIsaEntity is declared... no <youpi>check in the old log whether it *used* to be found <youpi>you always have cross-check, between something that works and something that doesn't <youpi>and I guess the fact that the probe function gets NULL is not actually a concern <youpi>since the driver *did* work without it <youpi>so continue checking for libpciaccess-enabled code in vesa.c <almuhs>static Bool VESAPciProbe(DriverPtr drv, int entity_num, <almuhs> struct pci_device *dev, intptr_t match_data); <youpi>also, see that the code is not using printfs, but xf86DrvMsg() <youpi>so use that to print your debugging lines <almuhs>i need the definition of DriverPtr and struct pci_device. They are not in the vesa code <youpi>I believe for a first step all you need is to put debugging prints to check which pieces of code are getting called, are running correctly or returning an error <youpi>no need to dive into more details <youpi>once you get a line that seems to produce an error, you'll dive more precisely <youpi>I believe for a first step all you need is to put debugging prints to check which pieces of code are getting called, are running correctly or returning an error <youpi>no need to dive into more details <youpi>once you get a line that seems to produce an error, you'll dive more precisely <almuhs>i want to show the device and driver data in the print <youpi>actually I don't think it will be useful <youpi>before spending time on printing details <youpi>rather spend time on printing which pieces of code actually get called <youpi>so that you only spend time on printing details *there* <youpi>thus reducing the amount of time you spend altogether <almuhs>i want to show the call to this function <almuhs>VESAPciProbe(DriverPtr drv, int entity_num, struct pci_device *dev, <youpi>then just put an x86msg call in it <youpi>no need for anything more fancy <youpi>I'd just recommend putting the call in other functions as well <youpi>you can use __func__ to get the function name as a char* <youpi>then you can just copy/paste the same print line in all the functions you'd like <youpi>you can also use __LINE__ to get the line number as an int <youpi>that way you can have a single line of code that you just copy/paste everywhere you'd like to check that the driver is going through it <almuhs>what is the syntax of xf86DrvMsg? <almuhs>youpi: "func undeclared". maybe do you refers to put the function name in the message? <youpi>with double-underscores both on left and right <almuhs>double underscores. It was missing <almuhs>my IRC client doesn't shows underscores <youpi>if it doesn't print you verbatim what we say, with C code that can be a *real* concern <almuhs>what IRC client do you recommends? I'm using Xchat <azeem>it might think it was markdown <azeem>though not sure xchat does that <youpi>personally I use pidgin, to manage not only IRC, but also XMPP, discord, etc. <almuhs>I used pidgin many years ago to XMPP <youpi>(and ditto for __LINE__ which has double-underscores on left & right) <almuhs>I go out. I will try to open IRC in pidgin <youpi>yay, the pflocal fix fixed the pflocal crash during building at-spi2-atk <youpi>probably it'll fix some other packages that were posing problem <AlmuHS>added prints. I've just packaged vesa. now rebooting <youpi>(too used to students who forget to save, forget to compile, forget to run from the proper directory, etc.) <AlmuHS>yes, I had this error many times <AlmuHS>upload the binary before compile :) <youpi>non-beginners also have, but remember to check whether they thought doing it <swivel>irssi for me but i like console tools <youpi>AlmuHS: Mmm, actually you shouldn't need to reboot? <youpi>if you have all the toolchain etc. in your hurd, you can recompile, install, retry starting Xorg <youpi>spending some time on making that loop as small as possible is what will save you a lot of time in the long run <AlmuHS>yes, but I was not sure about the previous version could be loaded in memory <youpi>Xorg reloads the .so each time it starts <AlmuHS>btw, where can i see the prints of vesa driver? <azeem>just today I made some fixes in a failed build in a schroot and then forgot to copy them over before I later continued the build <youpi>(that's why I told you to use the xf86 msg calls) <AlmuHS>but I don't see the messages into Xorg log <youpi>do you have "driver for VESA chipsets" showing up ? <youpi>I really mean the 4 words I mentioned <youpi>in some previous picture you showed, it was printing "VESA: driver for VESA chipsets: vesa" <youpi>did you put a print in the VESAPciProbe function for instance ? <youpi>did you try to put bogus C code to make sure that it was getting compiled-in? <AlmuHS>[551245.972] (II) VESA: driver for VESA chipsets: vesa <youpi>ok, so at least it does get loaded <youpi>yes, you can put #error foo for instance <youpi>just to make sure what you think is getting compiled, is actually getting compiled <youpi>as I said, always cross-check <youpi>otherwise you'd assume something, and possibly it's actually not happening <youpi>did you put a messabge in VESAPreInit ? <youpi>baiscally, I'd say add a message to each function that is referenced from the VESAInitScrn structure <youpi>to make sure of what gets called from Xorg <AlmuHS>I added prints in the lines hide under libpciaccess directive <youpi>AIUI they'd get called in the Probe, PreInit, ScreenInit, SwitchMode order <youpi>and thus you can add prints in the last one that does get called (and possibly does stuff that prevents the next from getting called) <AlmuHS>I have prints in Probe and PreInit, but not ScreenInit <youpi>(don't put prints only inside the libpciaccess code, but also before, to be sure whether you're entering them at allà) <AlmuHS>I'm editing file through ssh using nano, It's so lazy <youpi>better use a more advanced editor, to be efficient <swivel>unless you're unfamiliar with the more advanced editor, then it becomes far less efficient ;) <swivel>e.g. spending 15 minutes figuring out how to quit <youpi>well, anything you are used to :) <youpi>you should learn using a text editor <youpi>that'll save you in so many situations <youpi>(the exact editor doesn't matter that much actually, just make sure to learn its features in order to be efficient) <youpi>then I'd advise learning vim for real <youpi>it's available basically on all unices <youpi>even the dumbest unix boxes you might have in a drawer <swivel>even bare vi is pretty powerful and tends to be available everywhere... but once you go down the vim rabbithole things get pretty weird in a good way, just can make it awkward to interact with classic vi <janneke>hmm, any hope my x60's e1000e network adapter works? <youpi>janneke: netdde seems to have a driver for that <AlmuHS>janneke: my t60 network adapter works (ethernet, not wifi) <janneke>i haven't found the kernel messages eiter <AlmuHS>you can use "more" to read the log easily <AlmuHS>or even "less" to allow up and down <youpi>so you'd rather cat to a file, and then read that file <janneke>hmm, rekado added the netdde package, but it seems i failed to install it <janneke>i need to run "guix reconfigure" from linux again and install the netdd package (tomorrow!) <AlmuHS>youpi: there are not any of my messages in the Xorg log <youpi>is the date of the file really recent? <youpi>to make sure, put a message in VESAIdentify <youpi>that's the one printing "driver for VESA chipstes" <swivel>FWIW at some point on debian/linux Xorg stopped logging @ /var/log/Xorg.0.log and started logging in ~/.local/share/xorg/Xorg.0.log , I believe it coincided with shifting from Xorg run as root to run as a regular user w/modesetting driver. May or may not relate to what you're doing. <youpi>that's why I asked for checking the time of the file <AlmuHS>the time is recent, but maybe the /var/log has only basic info <AlmuHS>.local/share/xorg doesn't exists in my machine