Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #179761 > unrolled thread
| Started by | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| First post | 2017-04-04 16:10 +0200 |
| Last post | 2017-04-11 12:40 +0200 |
| Articles | 20 on this page of 23 — 5 participants |
Back to article view | Back to linux.debian.user
Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-04 16:10 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie Felix Miata <mrmazda@earthlink.net> - 2017-04-04 16:30 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-04 20:30 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie Felix Miata <mrmazda@earthlink.net> - 2017-04-05 02:10 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-09 12:30 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie Felix Miata <mrmazda@earthlink.net> - 2017-04-09 15:30 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie Felix Miata <mrmazda@earthlink.net> - 2017-04-09 16:30 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-09 17:20 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie Felix Miata <mrmazda@earthlink.net> - 2017-04-10 06:10 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-10 12:20 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-10 13:30 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie Felix Miata <mrmazda@earthlink.net> - 2017-04-10 14:40 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-10 16:40 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie Felix Miata <mrmazda@earthlink.net> - 2017-04-10 20:00 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-10 22:50 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie Felix Miata <mrmazda@earthlink.net> - 2017-04-11 01:00 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-11 14:50 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie Felix Miata <mrmazda@earthlink.net> - 2017-04-11 20:00 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie David Wright <deblis@lionunicorn.co.uk> - 2017-04-11 20:50 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-09 18:30 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie songbird <songbird@anthive.com> - 2017-04-04 21:00 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie deloptes <deloptes@gmail.com> - 2017-04-10 23:30 +0200
Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-11 12:40 +0200
Page 1 of 2 [1] 2 Next page →
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-04 16:10 +0200 |
| Subject | Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tsxjI-5Ua-41@gated-at.bofh.it> |
I installed several times 8.7.1 LXDE and as soon as I forced Stretch on it it will boot up but will not bring up a graphic display. Attempts to revert and/or switch from LightDM to LXDM did not cure the problem. The second time I updated 8.7.1 to its latest and then tried to make the switch to Debian9. Trying to boot up with Linux 3.18 didn't have any effect. The screen flashed some colors trying to bring up the DM but it remains black afterwards. So the third time I just reinstalled and updated 8.7.1 to its current stable state and it runs fine (slow but one heck faster than windows). I wonder if anyone else has similar problems and such problems have been reported. I tried to look through the bug maze but did not find anything. Next visit up there I will record the details of Hardware to post. 1024x768 is the max resolution it can handle and with the low memory it has, some "windows" like synaptic or firefox, when you try to move them around it seems like it takes forever, like it virtually tries to erase the picture from one pixel to draw the next. This is not a problem as there is nothing within the system worth saving, it was just an exercise to fix and backup old data from a WinXP that had become a mesh (pictures, documents, etc). I used about 8Gb of free disk to install Debian to backup the rest of the 80GB drive. This must be a 15y old machine, at least. I think it is a very early Celeron processor with about 256k video memory. Still, if Debian8 runs why does Debian9 fail? Simple upgrade from 8 to 9, nothing else changed. As soon as the update/grade finished and it is rebooted it is all black. Scraping the LXDE/lightdm/Openbox the login screen works fine and runs apt and everything else just fine. No graphic display, that's all. kAt -- "The most violent element in society is ignorance" rEG
[toc] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-04-04 16:30 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tsxD3-61f-1@gated-at.bofh.it> |
| In reply to | #179761 |
GiaThnYgeia composed on 2017-04-04 13:51 (UTC): ... > This must be a 15y old machine, at least. I think it is a very early Celeron > processor with about 256k video memory. What do 'lspci | grep VGA' and/or 'inxi -c0 -v1' show? > Still, if Debian8 runs why does Debian9 fail? Simple upgrade from 8 to > 9, nothing else changed. Kernel changed from 3.16 to 4.9, big difference if you have the wrong gfxchip: https://lists.debian.org/debian-user/2017/03/msg01326.html -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-04 20:30 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tsBnk-6X-21@gated-at.bofh.it> |
| In reply to | #179762 |
Felix Miata: > GiaThnYgeia composed on 2017-04-04 13:51 (UTC): > ... >> This must be a 15y old machine, at least. I think it is a very early >> Celeron > processor with about 256k video memory. > > What do 'lspci | grep VGA' and/or 'inxi -c0 -v1' show? One of the reasons I wrote the post is to get a list of stuff that I will have to record when I go back. It may take another day. >> Still, if Debian8 runs why does Debian9 fail? Simple upgrade from 8 >> to > 9, nothing else changed. > Kernel changed from 3.16 to 4.9, big difference if you have the wrong > gfxchip: > https://lists.debian.org/debian-user/2017/03/msg01326.html I know, so I did not delete the 3.16 when the 4.9 was installed. I tried booting up with 3.16 but it made no difference. Same color lines flashed once the bootup text was gone and it tried to bring up the graphical part. Even from recovery trying to bring something up manually it run into the same. I am a bit hasty on the procedure of building up the running kernel, it may start as 3.16 but it incorporates other drivers into the kernel when something like LightDM is attempted, right? So even if the 3.16 kernel is the same it brings up graphics related code from Debian9 that is different from 8. Here my USB installed systems may have some use, for someone who has valuable data on a system to try the upgrade on a different drive before messing up their long developed system. I just didn't have any 32bit ones. Funny thing (kudos to the tails team) that has testing and unstable stuff all mixed up in there ..... it DID run! I noticed the kernel is built on 4.8 and it is 32bit (I think there is going to be one last 2.12 32bit edition and then all tails3 will be 64bit only). But I think live systems incorporate a lot of code that makes them more adopting to hardware than permanent installations. -- "The most violent element in society is ignorance" rEG
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-04-05 02:10 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tsGGm-3zJ-3@gated-at.bofh.it> |
| In reply to | #179772 |
GiaThnYgeia composed on 2017-04-04 18:22 (UTC): > Felix Miata: >> GiaThnYgeia composed on 2017-04-04 13:51 (UTC): >> ... >>> Still, if Debian8 runs why does Debian9 fail? Simple upgrade from 8 >>> to > 9, nothing else changed. >> Kernel changed from 3.16 to 4.9, big difference if you have the wrong >> gfxchip: >> https://lists.debian.org/debian-user/2017/03/msg01326.html > I know, so I did not delete the 3.16 when the 4.9 was installed. I > tried booting up with 3.16 but it made no difference. Well, the server changed a lot too, from 1.16.4 to 1.19.2. Until we know what gfxchip you have there's little or no more help to offer. In addition to 'lspci | grep VGA' and/or 'inxi -c0 -v1', before this is solved likely we'll need at least Xorg.0.log, plus dmesg and/or output from journalctl. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-09 12:30 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tuigy-1wq-15@gated-at.bofh.it> |
| In reply to | #179788 |
[Multipart message — attachments visible in raw view] — view raw
See attached file for complete lshw of the failed stretch upgrade Felix Miata: > GiaThnYgeia composed on 2017-04-04 18:22 (UTC): > >> Felix Miata: > >>> GiaThnYgeia composed on 2017-04-04 13:51 (UTC): >>> ... >>>> Still, if Debian8 runs why does Debian9 fail? Simple upgrade from 8 >>>> to > 9, nothing else changed. >>> Kernel changed from 3.16 to 4.9, big difference if you have the wrong >>> gfxchip: >>> https://lists.debian.org/debian-user/2017/03/msg01326.html > >> I know, so I did not delete the 3.16 when the 4.9 was installed. I >> tried booting up with 3.16 but it made no difference. > Well, the server changed a lot too, from 1.16.4 to 1.19.2. > > Until we know what gfxchip you have there's little or no more help to > offer. In addition to 'lspci | grep VGA' and/or 'inxi -c0 -v1', before > this is solved likely we'll need at least Xorg.0.log, plus dmesg and/or > output from journalctl. I did not check the Xorg.0.log when the upgrade failed the DM and there is a new Jessie installation on it now which works fine (slow as hell but fine .. light years faster than WinXP though). It is not mine to mess with it anymore, I simply installed debian as a toolbox to cure and backup old data from the drive on that machine. I think with a meg or two of Ram this could be a very functional computer for a kid to learn debian. The processor is much faster than I thought it was but the ram is less than I thought. I know nothing about graphics hardware listed on lshw If the attachment fails I will copy paste the xml output here on the next message. Again the installation was done once with a 8.7.1-lxde-i386 disk and upgraded to stretch before an update. When it failed to bring up the display on reboot I thought it might be due to a mix up of dependencies because of the lack of update (from which 8.7.1 is not that far back). The second time libreoffice and gimp were removed to lighten-up and speed up update and upgrade. The update of Jessie was complete before the switch to testing was attempted. There was a reboot in its step to be able to identify where exactly the failure takes place. Same exact result, it will boot up and work fine on the prompt of recovery and any efforts to bring up an X or LX display failed. So now it is on Jessie stable and updated and all works fine with a bunch of other packages installed. All previous installation logs were lost. I speculate it is some graphics firmware that is no longer available on Stretch but is active on Jessie. -- "The most violent element in society is ignorance" rEG
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-04-09 15:30 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tul4K-3km-11@gated-at.bofh.it> |
| In reply to | #179915 |
GiaThnYgeia composed on 2017-04-09 10:22 (UTC): > See attached file for complete lshw of the failed stretch upgrade You need to do it again but without lshw outputting in xml format. With no switches lshw outputs in plain text, exactly the right format for an email attachment. However: 'inxi -c0 -Gx' should be all we need to address this thread subject, as would the lscpi or inxi commands suggested in a previous thread response. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-04-09 16:30 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tum0N-3WS-5@gated-at.bofh.it> |
| In reply to | #179920 |
GiaThnYgeia composed on 2017-04-09 13:45 (UTC):
> Felix Miata:
>> GiaThnYgeia composed on 2017-04-09 10:22 (UTC):
>>> See attached file for complete lshw of the failed stretch upgrade
>> You need to do it again but without lshw outputting in xml format. With
>> no switches lshw outputs in plain text, exactly the right format for an
>> email attachment.
>> However:
>> 'inxi -c0 -Gx' should be all we need to address this thread subject, as
>> would the lscpi or inxi commands suggested in a previous thread response.
> I am not physically there anymore, this is what they sent me.
> Power Management bus mastering PCI capabilities listing VGA compatible
> controller VT8375 [ProSavage8 KM266/KL266] [5333:8D04] S3 Graphics Ltd.
> [5333] 0 pci@0000:01:00.0 00 32 66000000
The ProSavage8 S3 Graphics gfxchip described there, which has no KMS support and
thus requires a user-space driver, fits into the following description from Stretch:
zcat /usr/share/doc/linux-image-amd64/NNEWS.Debian.gz:
linux-latest (76) unstable; urgency=medium
* From Linux 4.8, several changes have been made in the kernel
configuration to 'harden' the system, i.e. to mitigate security bugs.
Some changes may cause legitimate applications to fail, and can be
reverted by run-time configuration:
- On most architectures, the /dev/mem device can no longer be used to
access devices that also have a kernel driver. This breaks dosemu
and some old user-space graphics drivers. To allow this, set the
kernel parameter: iomem=relaxed
IOW, it is suggested that iomem=relaxed may need to be included on kernel
cmdline for the old user-space xserver-xorg-video-savage driver to work with
your gfxchip in Stretch.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-09 17:20 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tumNb-4uW-1@gated-at.bofh.it> |
| In reply to | #179922 |
Felix Miata: > IOW, it is suggested that iomem=relaxed may need to be included on > kernel cmdline for the old user-space xserver-xorg-video-savage driver > to work with your gfxchip in Stretch. Thank you for the help in answering the puzzle, but how is a semi-i-literate person able to translate this into a command/procedure that will achieve such a thing? IOW, I am clueless at this point of what a kernel cmdline is. I suspect it is a parameter in some file that builds up the kernel during boot ... but where is it and how do I add this command/parameter in it? Thank you again kAt PS During vacation time I have promissed to give linux-from-scratch a try, just to understand the necessary steps that build up the system. -- "The most violent element in society is ignorance" rEG
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-04-10 06:10 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tuyOl-46w-3@gated-at.bofh.it> |
| In reply to | #179924 |
GiaThnYgeia composed on 2017-04-09 15:16 (UTC): > Felix Miata composed: >> IOW, it is suggested that iomem=relaxed may need to be included on >> kernel cmdline for the old user-space xserver-xorg-video-savage driver >> to work with your gfxchip in Stretch. > Thank you for the help in answering the puzzle, but how is a > semi-i-literate person able to translate this into a command/procedure > that will achieve such a thing? IOW, I am clueless at this point of > what a kernel cmdline is. I suspect it is a parameter in some file that > builds up the kernel during boot ... but where is it and how do I add > this command/parameter in it? "kernel cmdline" is also known as "Kernel Command-Line". This is the group of parameters that are provided to the kernel and init system by the bootloader as a component of using its menu. See ‘GRUB_CMDLINE_LINUX’ and following on https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html for more detail as pertains to the bootloader Stretch normally installs. The cmdline last applied can be view by 'cat /proc/cmdline'. Alternatively, the cmdline last applied before Xorg was started can be found by viewing the first several lines of Xorg.0.log. What goes onto the cmdline can be configured either by 1-reconfiguring the bootloader after a successful boot (usually via changes to /etc/default/grub, then having grub write a new /boot/grub/grub.cfg file with grub-mkconfig), or 2-while the bootloader is showing its menu after POST has completed, to make a change applicable to the boot about to be started only (usually by hitting the "e" key while the menu is onscreen". #2 is what I was suggesting you first try to see if iomem=relaxed can solve the problem you have using your ProSavage8 S3 Graphics gfxchip. If it works then you should apply method #1. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-10 12:20 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tuEAq-7Nw-11@gated-at.bofh.it> |
| In reply to | #179942 |
Felix Miata: > GiaThnYgeia composed on 2017-04-09 15:16 (UTC): > >> Felix Miata composed: > >>> IOW, it is suggested that iomem=relaxed may need to be included on >>> kernel cmdline for the old user-space xserver-xorg-video-savage driver >>> to work with your gfxchip in Stretch. > >> Thank you for the help in answering the puzzle, but how is a >> semi-i-literate person able to translate this into a command/procedure >> that will achieve such a thing? IOW, I am clueless at this point of >> what a kernel cmdline is. I suspect it is a parameter in some file that >> builds up the kernel during boot ... but where is it and how do I add >> this command/parameter in it? > > "kernel cmdline" is also known as "Kernel Command-Line". This is the > group of parameters that are provided to the kernel and init system by > the bootloader as a component of using its menu. See > ‘GRUB_CMDLINE_LINUX’ and following on > https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html > > for more detail as pertains to the bootloader Stretch normally installs. Would this be IT? sudo nano /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet iomem=relaxed" sudo update-grub As there is no term iomem in any debian installation I searched on the net to find where and how does it relate to the kcl nor are any explicit instructions on the link you send me. I appreciate your help but imagine how much help would that be to one having such a machine and making the mistake to break the system to the almost stable Debian. Advice? Do not ever change much in your system withour having a functional live system you can boot and find instructions to help solve your broken system! In this case we have a system with a 2.4Ghz Celeron not being supported by Debian9 .... let us not beat around the bush about it! > The cmdline last applied can be view by 'cat /proc/cmdline'. > > Alternatively, the cmdline last applied before Xorg was started can be > found by viewing the first several lines of Xorg.0.log. > > What goes onto the cmdline can be configured either by > > 1-reconfiguring the bootloader after a successful boot (usually via > changes to /etc/default/grub, then having grub write a new > /boot/grub/grub.cfg file with grub-mkconfig), or > > 2-while the bootloader is showing its menu after POST has completed, to > make a change applicable to the boot about to be started only (usually > by hitting the "e" key while the menu is onscreen". > > #2 is what I was suggesting you first try to see if iomem=relaxed can > solve the problem you have using your ProSavage8 S3 Graphics gfxchip. If > it works then you should apply method #1. "If it works" This is the key term here, unless you are an experienced developer/programmer Debian or Linux is not for you! To the vast majority of people using a) browser 60% b) wordprocessor/office 15% c) multimedia software 20% d) some pluginnplay software 4% e) misc. 1% linux is virtually useless/dangerous! If 32bit systems are no longer supported it should be stated with bold headlines. The fact that somewhere in the fine print there is an alert that "some" hardware may cause the upgrade from 8 to 9 will break your system, that actually takes "some knowledge" to interpret as such, is unacceptable. I understand that this is debian-testing but for the past month we are under the impression this is stable any minute now after 2 years of testing. My understanding from reading this about iomem=relaxed is that such issues will not be addressed before it becomes stable. Also by adding this parameter into the kernel you are being "relaxed" about many other things which exclude you from the "hardening" experience of the upgraded system. So by solving one bottleneck and getting a system to be functional you may be under the illusion you are sharing the security and stability issues with everyone else, which is now false. It is false because simply your stretch is not what everyone else is running. And I see that people with much more recent 64bit hardware have had problem recently, like when linux4.8 went to 4.9. I now understand better why people are so hesitant in sticking with Debian 6 or 7 even if it will no longer be supported except major security issues. ------------------------------------ Come to think about it, if there was a single package in a live system or part of the installer that read your hardware in advance and told you this and this piece of hardware which you have is not supported by this Debian release you are about to install/upgrade. DO NOT UPGRADE or do so on your own risk of locating firmware to make it run. IOW block and prohibit someone like me from making a fatal mistake of breaking an otherwise functional system. It sounds more honest. The system has been tested in this database of hardware combinations and works. Anything else is "experimental". -- "The most violent element in society is ignorance" rEG "Who died and made you the superuser?" Brooklinux
[toc] | [prev] | [next] | [standalone]
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-10 13:30 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tuFGa-8rl-29@gated-at.bofh.it> |
| In reply to | #179948 |
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847154 > * From Linux 4.8, several changes have been made in the kernel > configuration to 'harden' the system, i.e. to mitigate security bugs. > Some changes may cause legitimate applications to fail, and can be > reverted by run-time configuration: > - On 64-bit PCs (amd64), the old 'virtual syscall' interface is > disabled. This breaks (e)glibc 2.13 and earlier. To re-enable it, > set the kernel parameter: vsyscall=emulate > - On most architectures, the /dev/mem device can no longer be used to > access devices that also have a kernel driver. This breaks dosemu > and some old user-space graphics drivers. To allow this, set the > kernel parameter: iomem=relaxed > - The kernel log is no longer readable by unprivileged users. To > allow this, set the sysctl: kernel.dmesg_restrict=0 > > > -- Ben Hutchings <ben@decadent.org.uk> Sat, 29 Oct 2016 02:05:32 +0100 > > $ GiaThnYgeia: > Felix Miata: >> GiaThnYgeia composed on 2017-04-09 15:16 (UTC): >> >>> Felix Miata composed: >> >>>> IOW, it is suggested that iomem=relaxed may need to be included on >>>> kernel cmdline for the old user-space xserver-xorg-video-savage driver >>>> to work with your gfxchip in Stretch. >> >>> Thank you for the help in answering the puzzle, but how is a >>> semi-i-literate person able to translate this into a command/procedure >>> that will achieve such a thing? IOW, I am clueless at this point of >>> what a kernel cmdline is. I suspect it is a parameter in some file that >>> builds up the kernel during boot ... but where is it and how do I add >>> this command/parameter in it? >> >> "kernel cmdline" is also known as "Kernel Command-Line". This is the >> group of parameters that are provided to the kernel and init system by >> the bootloader as a component of using its menu. See >> ‘GRUB_CMDLINE_LINUX’ and following on >> https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html >> >> for more detail as pertains to the bootloader Stretch normally installs. > > Would this be IT? > > sudo nano /etc/default/grub > GRUB_CMDLINE_LINUX_DEFAULT="quiet iomem=relaxed" > sudo update-grub > > As there is no term iomem in any debian installation I searched on the > net to find where and how does it relates to the kcl nor are any explicit > instructions on the link you send me. I appreciate your help but > imagine how much help would that be to one having such a machine and > making the mistake to break the system to the almost stable Debian. > > Advice? Do not ever change much in your system withour having a > functional live system you can boot and find instructions to help solve > your broken system! In this case we have a system with a 2.4Ghz Celeron > not being supported by Debian9 .... let us not beat around the bush > about it! > >> The cmdline last applied can be view by 'cat /proc/cmdline'. >> >> Alternatively, the cmdline last applied before Xorg was started can be >> found by viewing the first several lines of Xorg.0.log. >> >> What goes onto the cmdline can be configured either by >> >> 1-reconfiguring the bootloader after a successful boot (usually via >> changes to /etc/default/grub, then having grub write a new >> /boot/grub/grub.cfg file with grub-mkconfig), or >> >> 2-while the bootloader is showing its menu after POST has completed, to >> make a change applicable to the boot about to be started only (usually >> by hitting the "e" key while the menu is onscreen". >> >> #2 is what I was suggesting you first try to see if iomem=relaxed can >> solve the problem you have using your ProSavage8 S3 Graphics gfxchip. If >> it works then you should apply method #1. > > "If it works" > > This is the key term here, unless you are an experienced > developer/programmer Debian or Linux is not for you! To the vast > majority of people using a) browser 60% b) wordprocessor/office 15% c) > multimedia software 20% d) some pluginnplay software 4% e) misc. 1% > linux is virtually useless/dangerous! > > If 32bit systems are no longer supported it should be stated with bold > headlines. The fact that somewhere in the fine print there is an alert > that "some" hardware may cause the upgrade from 8 to 9 will break your > system, that actually takes "some knowledge" to interpret as such, is > unacceptable. > > I understand that this is debian-testing but for the past month we are > under the impression this is stable any minute now after 2 years of testing. > > My understanding from reading this about iomem=relaxed is that such > issues will not be addressed before it becomes stable. Also by adding > this parameter into the kernel you are being "relaxed" about many other > things which exclude you from the "hardening" experience of the upgraded > system. So by solving one bottleneck and getting a system to be > functional you may be under the illusion you are sharing the security > and stability issues with everyone else, which is now false. It is > false because simply your stretch is not what everyone else is running. > And I see that people with much more recent 64bit hardware have had > problems recently, like when linux4.8 went to 4.9. > > I now understand better why people are so hesitant in sticking with > Debian 6 or 7 even if it will no longer be supported except major > security issues. > > ------------------------------------ > > Come to think about it, if there was a single package in a live system > or part of the installer that read your hardware in advance and told you > this and this piece of hardware which you have is not supported by this > Debian release you are about to install/upgrade. DO NOT UPGRADE or do > so on your own risk of locating firmware to make it run. > IOW block and prohibit someone like me from making a fatal mistake of > breaking an otherwise functional system. It sounds more honest. The > system has been tested in this database of hardware combinations and > works. Anything else is "experimental". > > -- "The most violent element in society is ignorance" rEG "Who died and made you the superuser?" Brooklinux
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-04-10 14:40 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tuGLT-FF-3@gated-at.bofh.it> |
| In reply to | #179948 |
GiaThnYgeia composed on 2017-04-10 10:18 (UTC):
> Felix Miata:
>> GiaThnYgeia composed on 2017-04-09 15:16 (UTC):
>>> Felix Miata composed:
>>>> IOW, it is suggested that iomem=relaxed may need to be included on
>>>> kernel cmdline for the old user-space xserver-xorg-video-savage driver
>>>> to work with your gfxchip in Stretch.
>> "kernel cmdline" is also known as "Kernel Command-Line". This is the
>> group of parameters that are provided to the kernel and init system by
>> the bootloader as a component of using its menu. See
>> ‘GRUB_CMDLINE_LINUX’ and following on
>> https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html
>> for more detail as pertains to the bootloader Stretch normally installs.
> Would this be IT?
> sudo nano /etc/default/grub
> GRUB_CMDLINE_LINUX_DEFAULT="quiet iomem=relaxed"
> sudo update-grub
It would be #1 below, the step to take after proving that iomem=relaxed is
necessary for your Prosavage8 S3 Graphics gfxchip to work with 4.8 or newer
kernels.
zcat /usr/share/doc/linux-image-amd64/NNEWS.Debian.gz:
- On most architectures, the /dev/mem device can no longer be used to
access devices that also have a kernel driver. This breaks dosemu
and some old user-space graphics drivers. To allow this, set the
kernel parameter: iomem=relaxed
>> The cmdline last applied can be view by 'cat /proc/cmdline'.
>> Alternatively, the cmdline last applied before Xorg was started can be
>> found by viewing the first several lines of Xorg.0.log.
>> What goes onto the cmdline can be configured either by
>> 1-reconfiguring the bootloader after a successful boot (usually via
>> changes to /etc/default/grub, then having grub write a new
>> /boot/grub/grub.cfg file with grub-mkconfig), or
>> 2-while the bootloader is showing its menu after POST has completed, to
>> make a change applicable to the boot about to be started only (usually
>> by hitting the "e" key while the menu is onscreen".
>> #2 is what I was suggesting you first try to see if iomem=relaxed can
>> solve the problem you have using your ProSavage8 S3 Graphics gfxchip. If
>> it works then you should apply method #1.
> "If it works"
> This is the key term here, unless you are an experienced
> developer/programmer Debian or Linux is not for you! To the vast
> majority of people using a) browser 60% b) wordprocessor/office 15% c)
> multimedia software 20% d) some pluginnplay software 4% e) misc. 1%
> linux is virtually useless/dangerous!
> If 32bit systems are no longer supported it should be stated with bold
> headlines. The fact that somewhere in the fine print there is an alert
> that "some" hardware may cause the upgrade from 8 to 9 will break your
> system, that actually takes "some knowledge" to interpret as such, is
> unacceptable.
This is not so much about 32 bit as it is about old gfx hardware for which
drivers have not been adapted to the KMS model on which more modern gfxchips
depend and succeed.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-10 16:40 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tuIE2-1UB-7@gated-at.bofh.it> |
| In reply to | #179951 |
Felix Miata: > GiaThnYgeia composed on 2017-04-10 10:18 (UTC): >> Felix Miata: >> Would this be IT? >>1 sudo nano /etc/default/grub >>2 GRUB_CMDLINE_LINUX_DEFAULT="quiet iomem=relaxed" >>3 sudo update-grub > > It would be #1 below, the step to take after proving that iomem=relaxed > is necessary for your Prosavage8 S3 Graphics gfxchip to work with 4.8 or > newer kernels. >>> 1-reconfiguring the bootloader after a successful boot (usually via >>> changes to /etc/default/grub, then having grub write a new >>> /boot/grub/grub.cfg file with grub-mkconfig), or Again, I appreciate you helping me trying to help someone to be introduced to debian but those three lines above (1-2-3) do not equal those below (1-). In your understanding and knowledge base maybe, but not everyone who may be trying to use Debian instead of a non-free system will see them as equal. People watching the weather forecast do not need to take 3 semesters of thermodynamics and meteorology to understand whether they should take an umbrella to work or not. Are you saying they shouldn't watch the weather forecast on Debian? It may be too early to speak, but once the debian-installer-9 (Stretch is released) if this is the outcome for "ANY" system I think my constructive criticism of being "experimental" will be well founded. One should not have to do this to get a "stable" system installed! >> "If it works" > >> This is the key term here, unless you are an experienced >> developer/programmer Debian or Linux is not for you! To the vast >> majority of people using a) browser 60% b) wordprocessor/office 15% c) >> multimedia software 20% d) some pluginnplay software 4% e) misc. 1% >> linux is virtually useless/dangerous! > >> If 32bit systems are no longer supported it should be stated with bold >> headlines. The fact that somewhere in the fine print there is an alert >> that "some" hardware may cause the upgrade from 8 to 9 to break your >> system, that actually takes "some knowledge" to interpret as such, is >> unacceptable. > > This is not so much about 32 bit as it is about old gfx hardware for > which drivers have not been adapted to the KMS model on which more > modern gfxchips depend and succeed. I see no bold headlines saying "this New Release of Debian may break your system, better stick to Jessie unless you have new hardware". To which you may respond it is not Debian's fault but Linux4.8+. !!! Stick to 4.7 then, damn it! But the security people disagree. AND, Yes, but is anything preventing someone from installing Stretch and breaking a good system, aka Jessie! And if the problem lies internally within the linux4.8+ why isn't it booting up to a graphics login screen with linux3.16, the same that was left from Jessie? Again you are responding technically in solving a technical problem that I presented. For this I thank you. What I am now saying is that it is unacceptable as a practice. At least there should be a patch installed of listed unsupported hardware that once detected during upgrade it reconfigures the boot manager with your suggested modification. Or refuses the upgrade on the premises of "no longer supported" hardware. I don't think too many people will put up with a broken system, trying to use lynx or emacs to find or get responses as yours to fix a system that a few hours before was running fine. Should a live system based on Stretch have the same problem? In other words, when a Debian-Stretch-9.0-Lxde-i386.iso is released will it boot on this same hardware? I wouldn't think so. But the Jessie8.7.1-live-i386 run fine. The questioning is not directed to you trying to help but to those that make such decisions to allow such things to happen. If editing grub or lilo and adding a line fixes the installation it should be done automatically, not allow a broken system and a user trying to find out what has happened. A notice would be nice "your system must now reboot to modify the installation based on your no-longer-supported hardware". I think I have done my share of reporting and complaining to let the issue rest for "higher authorities" to decide whether something should be done. I don't think gfx hdw were produced in limited numbers, I think there are thousands of them out. -- "The most violent element in society is ignorance" rEG "Who died and made you the superuser?" Brooklinux
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-04-10 20:00 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tuLLC-3YK-77@gated-at.bofh.it> |
| In reply to | #179957 |
GiaThnYgeia composed on 2017-04-10 14:32 (UTC): > you are responding technically in solving a technical problem that > I presented. For this I thank you. What I am now saying is that it is > unacceptable as a practice. At least there should be a patch installed > of listed unsupported hardware that once detected during upgrade it > reconfigures the boot manager with your suggested modification. Or > refuses the upgrade on the premises of "no longer supported" hardware. Debian-user is a user support forum, not a developer forum: Debian Mailing Lists debian-user Community assistance and support for Debian users. Support for Debian users who speak English. https://lists.debian.org/debian-user/ For bug fixes and policy modifications debian-user is the wrong place for more than passing discussion. I suggest other avenues: https://lists.debian.org/debian-devel/ mailing list https://www.debian.org/Bugs/ bug tracker irc://freenode/#debian-next IRC http://forums.debian.net/ Debian development forum -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-10 22:50 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tuOq6-5Lj-13@gated-at.bofh.it> |
| In reply to | #179959 |
Felix Miata: > GiaThnYgeia composed on 2017-04-10 14:32 (UTC): > >> you are responding technically in solving a technical problem that >> I presented. For this I thank you. What I am now saying is that it is >> unacceptable as a practice. At least there should be a patch installed >> of listed unsupported hardware that once detected during upgrade it >> reconfigures the boot manager with your suggested modification. Or >> refuses the upgrade on the premises of "no longer supported" hardware. > > Debian-user is a user support forum, not a developer forum: > > Debian Mailing Lists > debian-user > Community assistance and support for Debian users. > Support for Debian users who speak English. > https://lists.debian.org/debian-user/ 1st of all, does this mean you have no opinion on the issue? 2nd does this mean that nobody here should express an opinion about it? I beg to differ. > For bug fixes and policy modifications debian-user is the wrong place > for more than passing discussion. I suggest other avenues: > > https://lists.debian.org/debian-devel/ mailing list > https://www.debian.org/Bugs/ bug tracker > irc://freenode/#debian-next IRC > http://forums.debian.net/ Debian development forum I am not a developer, nor will I pretend to be one. But in the strict sense of a "user" I have yet to see anyone here be a user. User in the sense of using someone's administered system without any administrative rights. Nor are we talking about a real bug, but a conscious decision to stop supporting some hardware that the unsuspecting victim may not be alerted about. Digging deep into some bug report of a year ago "implying" that some hardware may no longer be supported, does not constitute an alert. It appears more of a passive-aggressive excuse of an "I told you so" in the fine print. Furthermore, among developers, for ages (decades in this case), there is a closed culture developing over and over again, where the status-quo is defended without addressing an issue. Whatever is going on is just fine with us (developers) and if you don't like it, tough! What would you think will happen if I take my case to the developers list, me an outsider who dares not to understand what a kernel command mode is. Now if you are a developer or one is reading this feel free to transfer this criticism to the club. If Debian has become a foundation and a base for other systems to be based on, a developers' system, I think it needs to be more emphasized on the very first page of debian.org .... that this system is not for the average user, but it is directed as a base for developers to create systems. Which to me seems as a shift of policy of what Debian was. Should I repeat the initial problem? Install Debian8.7.1, log in, everything is fine. Update/Upgrade the system. Reboot ... everything nice. Switch from jessie to testing Update/upgrade ... still OK. Reboot Black screen no prompt! You say it is a known issue and a conscious decision. You have no opinion on the matter! It is how the cookie crumbles. Tell that to the person staring at a blank screen without any feedback or knowledge on what to do. What do you really expect the X0org.log to look like and how helpful would this be to someone with a single machine? -- "The most violent element in society is ignorance" rEG "Who died and made you the superuser?" Brooklinux
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-04-11 01:00 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tuQrT-72b-5@gated-at.bofh.it> |
| In reply to | #179962 |
GiaThnYgeia composed on 2017-04-10 20:40 (UTC): > Felix Miata composed: >> Debian-user is a user support forum, not a developer forum: >> Debian Mailing Lists >> debian-user >> Community assistance and support for Debian users. >> Support for Debian users who speak English. >> https://lists.debian.org/debian-user/ > 1st of all, does this mean you have no opinion on the issue? Which issue? This thread has more than one issue: 1-your Stretch is broken 2-you don't like not being warned in advance that upgrading from Jessie could break your installation > 2nd does this mean that nobody here should express an opinion about it? No. One can write about how one thinks things should be or change without going off topic too far, but for fruit to grow out of the effort, this forum is a poor choice in which to put it. My opinion is that people who want ancient hardware to continue to be supported for the longest possible period of time must participate in the development phase by testing on the very hardware that they want to stay working when it's hardware that developers either no longer have or no longer have motivation to use, and they must do so throughout development, not only in the final weeks before release is expected. When a problem is found, it needs to be timely reported according to distro policy in the proper place and manner. Reports in the debian-user mailing list are insufficient to fulfill this purpose. >> For bug fixes and policy modifications debian-user is the wrong place >> for more than passing discussion. I suggest other avenues: >> https://lists.debian.org/debian-devel/ mailing list >> https://www.debian.org/Bugs/ bug tracker >> irc://freenode/#debian-next IRC >> http://forums.debian.net/ Debian development forum > I am not a developer, nor will I pretend to be one. But in the strict > sense of a "user" I have yet to see anyone here be a user. User in the > sense of using someone's administered system without any administrative > rights. If you are a user seeking help to get your installation working, this is the right place to start. If discussion here raises an issue that constitutes a previously unknown bug, discussion needs to be redirected to more suitable forum if a bug fix is desired rather than a place to complain that a bug exists. Developers don't often fix bugs that they don't know about. This is not a place where developers come looking to discover bugs to fix. > Nor are we talking about a real bug, but a conscious decision to stop > supporting some hardware ms as a shift of policy... You, not we. I'm not here to discuss any policy other than whether this thread's content is suitably located, and with this post I'm finished with this sub-thread. > Should I repeat the initial problem? > Install Debian8.7.1, log in, everything is fine. > Update/Upgrade the system. > Reboot ... everything nice. > Switch from jessie to testing > Update/upgrade ... still OK. > Reboot > Black screen no prompt! Did including iomem=relaxed on your cmdline solve your problem, or did it not? If yes, say so. If not, bring this to the attention of those who might be able to implement an acceptable-to-you solution or provide the pre-installation documentation with a warning that might better serve. Continuing to discuss a documentation or policy failure here is a waste of time. Supporting ancient hardware forever is not going to happen. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-11 14:50 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tv3p7-73W-3@gated-at.bofh.it> |
| In reply to | #179966 |
Felix Miata: > My opinion is that people who want ancient hardware to continue to be > supported for the longest possible period of time must participate in > the development phase by testing on the very hardware that they want to > stay working when it's hardware that developers either no longer have or > no longer have motivation to use, and they must do so throughout > development, not only in the final weeks before release is expected. I'll stick to the "people who want ancient hardware" and ask whether you perceive those people as having a choice to "want ancient" hardware or whether this is "all" they have. Do you anticipate those same people to be able to start their computing career in developing systems? Which relates to that world do we want Debian to prevail. The "free" world or the "non-free" world in which we live in? > When a problem is found, it needs to be timely reported according to > distro policy in the proper place and manner. Reports in the debian-user > mailing list are insufficient to fulfill this purpose. By who? By the person who just lost all graphical access to the system? By a bug-reporting system that I have yet to see ever working? Is a person installing debian expected to know how to access and communicate on the command screen of the -recovery mode? > You, not we. I'm not here to discuss any policy other than whether this > thread's content is suitably located, and with this post I'm finished > with this sub-thread. Me too ... dealing with such responses > Did including iomem=relaxed on your cmdline solve your problem, or did > it not? I wouldn't know, the person for which I installed Debian for will not dare switch to Stretch after this experience, will not even talk about it. Did you read about the person who used zsh as a login shell and upgraded Jessie to testing and got locked out of his system because zsh vanished? Good thing he knew how to deal with that crisis. > If yes, say so. Are you talking to me? I am one of this privileged well off people to have hardware that can run Stretch and Sid and all kinds of things. Send some snail-mail to the less privileged who have lost access to the net to ask them. > Supporting ancient hardware forever is not going to happen. A 2.33Mhz Celeron pc is by no means ancient compared to the Debian claims. -- "The most violent element in society is ignorance" rEG "Who died and made you the superuser?" Brooklinux
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-04-11 20:00 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tv8f8-1JB-19@gated-at.bofh.it> |
| In reply to | #179975 |
GiaThnYgeia composed on 2017-04-11 08:39 (UTC-0400): > Felix Miata: >> Did including iomem=relaxed on your cmdline solve your problem, or did >> it not? > I wouldn't know, the person for which I installed Debian for will not > dare switch to Stretch after this experience, will not even talk about > it. >> If yes, say so. > Are you talking to me? Who else would I be writing to? You started the thread: https://lists.debian.org/debian-user/2017/04/msg00091.html Presumably, you were the "I" with the Prosavage8 S3 Graphics problem about which you wrote. >> Supporting ancient hardware forever is not going to happen. > A 2.33Mhz Celeron pc is by no means ancient compared to the Debian claims. While that CPU may well be considered non-ancient, Debian dropped the ball when it integrated upstream's KMS without commensurate resources necessary to adapt and maintain drivers for all gfxchips other than those from AMD/ATI, Intel and NVidia. Support for the ~18 year old Prosavage8 S3 Graphics gfxchip that is the reason for this thread's inception has obviously become inadequate, as it has for a non-trivial number of other gfxchips designed 15-20 years ago. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-04-11 20:50 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tv91v-2ie-13@gated-at.bofh.it> |
| In reply to | #179975 |
On Tue 11 Apr 2017 at 12:39:00 (+0000), GiaThnYgeia wrote: > > > Felix Miata: > > My opinion is that people who want ancient hardware to continue to be > > supported for the longest possible period of time must participate in > > the development phase by testing on the very hardware that they want to > > stay working when it's hardware that developers either no longer have or > > no longer have motivation to use, and they must do so throughout > > development, not only in the final weeks before release is expected. > > I'll stick to the "people who want ancient hardware" and ask whether you > perceive those people as having a choice to "want ancient" hardware or > whether this is "all" they have. I would opine, from what I read, that if you want to run mainstream linux on ancient hardware, then Debian is a pretty good choice to make. If Debian doesn't support it because it lacks some feature now seen as essential, then I think you have to look to a specialist distribution/project run by people who just see these things as a challenge rather than as systems to use for productive work. > Do you anticipate those same people to > be able to start their computing career in developing systems? No idea what that means. > Which relates to that world do we want Debian to prevail. The "free" > world or the "non-free" world in which we live in? No point in using the word "free" without saying which meaning you're using. > > When a problem is found, it needs to be timely reported according to > > distro policy in the proper place and manner. Reports in the debian-user > > mailing list are insufficient to fulfill this purpose. > > By who? By the person who just lost all graphical access to the system? > By a bug-reporting system that I have yet to see ever working? > Is a person installing debian expected to know how to access and > communicate on the command screen of the -recovery mode? Yes, it's clever that...sort of Catch 22. That's why car breakdown companies invented Home-Start services, because you can't get to the garage. > > You, not we. I'm not here to discuss any policy other than whether this > > thread's content is suitably located, and with this post I'm finished > > with this sub-thread. > > Me too ... dealing with such responses > > > Did including iomem=relaxed on your cmdline solve your problem, or did > > it not? > > I wouldn't know, the person for which I installed Debian for will not > dare switch to Stretch after this experience, will not even talk about > it. So you're not the owner/user of this 2.33Mhz 650kRam PC but are supporting those who are? I doubt the wisdom of that. But it does explain why you also want a DE. By the time you add a browser and some modern web pages, I wonder what sort of performance they'll get. I got the impression from "What do you really expect the X0org.log to look like and how helpful would this be to someone with a single machine?" that you were afraid of breaking the system (in which case, why are you desparate to upgrade to stretch?). But then I looked further back and found that originally "it was just an exercise to fix and backup old data from a WinXP that had become a mesh". So I can't understand why you ask a question here and, when an answer is given, just refuse to try it, invent strange reasons to justify not trying it, and then rubbish Debian and the people here who try to help. > Did you read about the person who used zsh as a login shell and > upgraded Jessie to testing and got locked out of his system because zsh > vanished? Good thing he knew how to deal with that crisis. No, but when everything depends on one machine, you don't do stupid things like upgrading to testing. > > If yes, say so. > > Are you talking to me? I am one of this privileged well off people to > have hardware that can run Stretch and Sid and all kinds of things. > Send some snail-mail to the less privileged who have lost access to the > net to ask them. > > > Supporting ancient hardware forever is not going to happen. > > A 2.33Mhz Celeron pc is by no means ancient compared to the Debian claims. Debian is fulfilling its part of the bargain. It writes "Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law." People here support others out of the goodness of their hearts, but they are human. It you demand support tailored to yourself, then go and pay for it. There's no encumbrance from Debian; there might be some from the hardware and firmware manufacturers and you'll have to deal with that yourself. If you choose to go cheap by using ancient hardware, there's a trade-off: time and knowledge. If you run a vintage car, you'd better know how to fix it, or employ a chauffeur. If you drive one, you'd better know how to double de-clutch, adjust your mixture, advance the ignition, and so on. And, of course, you help others along the way. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | GiaThnYgeia <GiaThnYgeia@openmailbox.org> |
|---|---|
| Date | 2017-04-09 18:30 +0200 |
| Subject | Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie |
| Message-ID | <tunSV-5eR-1@gated-at.bofh.it> |
| In reply to | #179915 |
Sorry,
I made a mistake earlier and replied on the wrong thread (Re: [Stretch,
9.0] Installation failed to install net-tools (from scratch
installation)), here is the output again listed for reference, although
the riddle seems to be solved by Felix on this same thread.
Output at the bottom
GiaThnYgeia:
> See attached file for complete lshw of the failed stretch upgrade
>
> Felix Miata:
>> GiaThnYgeia composed on 2017-04-04 18:22 (UTC):
>>
>>> Felix Miata:
>>
>>>> GiaThnYgeia composed on 2017-04-04 13:51 (UTC):
>>>> ...
>>>>> Still, if Debian8 runs why does Debian9 fail? Simple upgrade from 8
>>>>> to > 9, nothing else changed.
>>>> Kernel changed from 3.16 to 4.9, big difference if you have the wrong
>>>> gfxchip:
>>>> https://lists.debian.org/debian-user/2017/03/msg01326.html
>>
>>> I know, so I did not delete the 3.16 when the 4.9 was installed. I
>>> tried booting up with 3.16 but it made no difference.
>> Well, the server changed a lot too, from 1.16.4 to 1.19.2.
>>
>> Until we know what gfxchip you have there's little or no more help to
>> offer. In addition to 'lspci | grep VGA' and/or 'inxi -c0 -v1', before
>> this is solved likely we'll need at least Xorg.0.log, plus dmesg and/or
>> output from journalctl.
>
> I did not check the Xorg.0.log when the upgrade failed the DM and there
> is a new Jessie installation on it now which works fine (slow as hell
> but fine .. light years faster than WinXP though). It is not mine to
> mess with it anymore, I simply installed debian as a toolbox to cure and
> backup old data from the drive on that machine.
>
> I think with a meg or two of Ram this could be a very functional
> computer for a kid to learn debian. The processor is much faster than I
> thought it was but the ram is less than I thought. I know nothing about
> graphics hardware listed on lshw
> If the attachment fails I will copy paste the xml output here on the
> next message.
>
> Again the installation was done once with a 8.7.1-lxde-i386 disk and
> upgraded to stretch before an update. When it failed to bring up the
> display on reboot I thought it might be due to a mix up of dependencies
> because of the lack of update (from which 8.7.1 is not that far back).
> The second time libreoffice and gimp were removed to lighten-up and
> speed up update and upgrade. The update of Jessie was complete before
> the switch to testing was attempted. There was a reboot in its step to
> be able to identify where exactly the failure takes place. Same exact
> result, it will boot up and work fine on the prompt of recovery and any
> efforts to bring up an X or LX display failed. So now it is on Jessie
> stable and updated and all works fine with a bunch of other packages
> installed. All previous installation logs were lost.
>
> I speculate it is some graphics firmware that is no longer available on
> Stretch but is active on Jessie.
>
I thought that I had never seen an attachment on the list before but I
was not sure. So here is the lazy output. (Power Management bus
mastering PCI capabilities listing VGA compatible controller VT8375
[ProSavage8 KM266/KL266] [5333:8D04] S3 Graphics Ltd. [5333] 0
pci@0000:01:00.0 00 32 66000000 )
Computer PROD00000000 OEM00000 32 SMBIOS version 2.2 SMP specification
v1.4 Symmetric Multi-Processing
Motherboard 0 Intel(R) Celeron(R) CPU 2.40GHz Intel Corp. 0 cpu@0 15.2.9
2500000000 32
boot processor mathematical co-processor FPU exceptions reporting
virtual mode extensions debugging extensions page size extensions time
stamp counter model-specific registers 4GB+ memory addressing (Physical
Address Extension) machine check exceptions compare and exchange 8-byte
on-chip advanced programmable interrupt controller (APIC) fast system
calls memory type range registers page global enable machine check
architecture conditional move instruction page attribute table 36-bit
page size extensions debug trace and EMON store MSRs thermal control
(ACPI) multimedia extensions (MMX) fast floating point save/restore
streaming SIMD extensions (SSE) streaming SIMD extensions (SSE2) self-snoop
HyperThreading thermal interrupt and status pending break event L1 cache
0 8192 System memory 1 242102272 Host bridge P4M266 Host Bridge
[1106:3148] VIA Technologies, Inc. [1106] 100 pci@0000:00:00.0 00 32
66000000 PCI bridge VT8633 [Apollo Pro266 AGP] [1106:B091] VIA
Technologies, Inc. [1106] 1 pci@0000:00:01.0 00 32 66000000
Power Management bus mastering PCI capabilities listing VGA compatible
controller VT8375 [ProSavage8 KM266/KL266] [5333:8D04] S3 Graphics Ltd.
[5333] 0 pci@0000:01:00.0 00 32 66000000
Power Management AGP AGP 2.0 bus mastering PCI capabilities listing USB
controller VT82xxxxx UHCI
USB 1.1 Controller [1106:3038] VIA Technologies, Inc. [1106] 10
pci@0000:00:10.0 80 32 33000000
Power Management Universal Host Controller Interface (USB1) bus
mastering PCI capabilities listing UHCI Host Controller [1D6B:1]
Linux 3.16.0-4-586 uhci_hcd [1D6B] 1 usb@1 usb1 3.16 USB 1.1 Mouse Basic
Optical Mouse [45E:83] Microsoft [45E] 2 usb@1:2 0.00 USB 1.1 USB
controller VT82xxxxx UHCI USB 1.1 Controller [1106:3038] VIA
Technologies, Inc. [1106] 10.1 pci@0000:00:10.1 80 32 33000000 Power
Management Universal Host Controller Interface (USB1) bus mastering PCI
capabilities listing UHCI Host Controller [1D6B:1] Linux 3.16.0-4-586
uhci_hcd [1D6B] 1 usb@3 usb3 3.16 USB 1.1 USB controller VT82xxxxx UHCI
USB 1.1 Controller [1106:3038] VIA Technologies, Inc. [1106] 10.2
pci@0000:00:10.2 80 32 33000000 Power Management Universal Host
Controller Interface (USB1) bus mastering PCI capabilities listing UHCI
Host Controller [1D6B:1] Linux 3.16.0-4-586 uhci_hcd [1D6B] 1 usb@4 usb4
3.16 USB 1.1 USB controller USB 2.0 [1106:3104] VIA Technologies, Inc.
[1106] 10.3 pci@0000:00:10.3 82 32 33000000 Power Management Enhanced
Host Controller Interface (USB2) bus mastering PCI capabilities listing
EHCI Host Controller [1D6B:2] Linux 3.16.0-4-586 ehci_hcd [1D6B] 1 usb@2
usb2 3.16 USB 2.0 ISA bridge VT8235 ISA Bridge [1106:3177] VIA
Technologies, Inc. [1106] 11 pci@0000:00:11.0 00 32 33000000 Power
Management bus mastering PCI capabilities listing IDE interface
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:571] VIA
Technologies, Inc. [1106] 11.1 pci@0000:00:11.1 06 32 33000000 Power
Management bus mastering PCI capabilities listing Multimedia audio
controller VT8233/A/8235/8237 AC97 Audio Controller [1106:3059] VIA
Technologies, Inc. [1106] 11.5 pci@0000:00:11.5 50 32 33000000 Power
Management PCI capabilities listing Ethernet interface VT6102 [Rhine-II]
[1106:3065] VIA Technologies, Inc. [1106] 12 pci@0000:00:12.0 eth0 74
00:0c:76:8e:f0:fd 100000000 100000000 32 33000000 Power Management bus
mastering PCI capabilities listing Physical interface twisted pair Media
Independent Interface 10Mbit/s 10Mbit/s (full duplex) 100Mbit/s
100Mbit/s (full duplex) Auto-negotiation 2 scsi0 Emulated device ATA
Disk ST340014A Seagate 0.0.0 scsi@0:0.0.0 /dev/sda 8:0 3.06 5JX73XSR
40020664320 Partitioned disk MS-DOS partition table Windows NTFS volume
1 scsi@0:0.0.0,1 /dev/sda1 8:1 3.1 de9c8852-4940-544b-8699-ae2047d3b2e8
29999964672 30000000000 Primary partition Bootable partition (active)
Windows NTFS initialized volume Extended partition 2 scsi@0:0.0.0,2
/dev/sda2 8:2 10019144704 10019144704 Primary partition Extended
partition Partitioned disk Extended partition Linux filesystem partition
5 /dev/sda5 / 8:5 9557770240 Linux swap / Solaris partition 6 /dev/sda6
8:6 460324864 No filesystem 3 scsi1 Emulated device DVD reader COMBO
LTC-48161H LITE-ON 0.0.0 scsi@1:0.0.0 /dev/cdrom /dev/cdrw /dev/dvd
/dev/sr0 /media/cdrom0 11:0 KH0P support is removable Audio CD playback
CD-R burning CD-RW burning DVD playback 0 /dev/cdrom /media/cdrom0 11:0
-- cut here for lshw XML file ------
<?xml version="1.0" standalone="yes" ?>
<!-- generated by lshw-B.02.17 -->
<!-- GCC 4.9.1 -->
<!-- Linux 3.16.0-4-586 #1 Debian 3.16.39-1+deb8u2 (2017-03-07) i686 -->
<!-- GNU libc 2 (glibc 2.19) -->
<list>
<node id="debian32bitjessie" claimed="true" class="system" handle="">
<description>Computer</description>
<product>PROD00000000</product>
<vendor>OEM00000</vendor>
<width units="bits">32</width>
<configuration>
<setting id="cpus" value="1" />
</configuration>
<capabilities>
<capability id="smbios-2.2" >SMBIOS version 2.2</capability>
<capability id="smp-1.4" >SMP specification v1.4</capability>
<capability id="smp" >Symmetric Multi-Processing</capability>
</capabilities>
<node id="core" claimed="true" class="bus" handle="">
<description>Motherboard</description>
<physid>0</physid>
<node id="cpu" claimed="true" class="processor" handle="">
<product>Intel(R) Celeron(R) CPU 2.40GHz</product>
<vendor>Intel Corp.</vendor>
<physid>0</physid>
<businfo>cpu@0</businfo>
<version>15.2.9</version>
<size units="Hz">2500000000</size>
<width units="bits">32</width>
<configuration>
<setting id="id" value="0" />
</configuration>
<capabilities>
<capability id="boot" >boot processor</capability>
<capability id="fpu" >mathematical co-processor</capability>
<capability id="fpu_exception" >FPU exceptions reporting</capability>
<capability id="wp" />
<capability id="vme" >virtual mode extensions</capability>
<capability id="de" >debugging extensions</capability>
<capability id="pse" >page size extensions</capability>
<capability id="tsc" >time stamp counter</capability>
<capability id="msr" >model-specific registers</capability>
<capability id="pae" >4GB+ memory addressing (Physical Address
Extension)</capability>
<capability id="mce" >machine check exceptions</capability>
<capability id="cx8" >compare and exchange 8-byte</capability>
<capability id="apic" >on-chip advanced programmable interrupt
controller (APIC)</capability>
<capability id="sep" >fast system calls</capability>
<capability id="mtrr" >memory type range registers</capability>
<capability id="pge" >page global enable</capability>
<capability id="mca" >machine check architecture</capability>
<capability id="cmov" >conditional move instruction</capability>
<capability id="pat" >page attribute table</capability>
<capability id="pse36" >36-bit page size extensions</capability>
<capability id="clflush" />
<capability id="dts" >debug trace and EMON store MSRs</capability>
<capability id="acpi" >thermal control (ACPI)</capability>
<capability id="mmx" >multimedia extensions (MMX)</capability>
<capability id="fxsr" >fast floating point save/restore</capability>
<capability id="sse" >streaming SIMD extensions (SSE)</capability>
<capability id="sse2" >streaming SIMD extensions (SSE2)</capability>
<capability id="ss" >self-snoop</capability>
<capability id="ht" >HyperThreading</capability>
<capability id="tm" >thermal interrupt and status</capability>
<capability id="pbe" >pending break event</capability>
<capability id="pebs" />
<capability id="bts" />
<capability id="cid" />
<capability id="xtpr" />
</capabilities>
<node id="cache" claimed="true" class="memory" handle="">
<description>L1 cache</description>
<physid>0</physid>
<size units="bytes">8192</size>
</node>
</node>
<node id="memory" claimed="true" class="memory" handle="">
<description>System memory</description>
<physid>1</physid>
<size units="bytes">242102272</size>
</node>
<node id="pci" claimed="true" class="bridge" handle="PCIBUS:0000:00">
<description>Host bridge</description>
<product>P4M266 Host Bridge [1106:3148]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>100</physid>
<businfo>pci@0000:00:00.0</businfo>
<version>00</version>
<width units="bits">32</width>
<clock units="Hz">66000000</clock>
<configuration>
<setting id="driver" value="agpgart-via" />
</configuration>
<resources>
<resource type="irq" value="0" />
<resource type="memory" value="e8000000-e9ffffff" />
</resources>
<node id="pci" claimed="true" class="bridge" handle="PCIBUS:0000:01">
<description>PCI bridge</description>
<product>VT8633 [Apollo Pro266 AGP] [1106:B091]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>1</physid>
<businfo>pci@0000:00:01.0</businfo>
<version>00</version>
<width units="bits">32</width>
<clock units="Hz">66000000</clock>
<capabilities>
<capability id="pci" />
<capability id="pm" >Power Management</capability>
<capability id="normal_decode" />
<capability id="bus_master" >bus mastering</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
</capabilities>
<resources>
<resource type="memory" value="ea000000-ebffffff" />
<resource type="memory" value="e0000000-e7ffffff" />
</resources>
<node id="display" class="display" handle="PCI:0000:01:00.0">
<description>VGA compatible controller</description>
<product>VT8375 [ProSavage8 KM266/KL266] [5333:8D04]</product>
<vendor>S3 Graphics Ltd. [5333]</vendor>
<physid>0</physid>
<businfo>pci@0000:01:00.0</businfo>
<version>00</version>
<width units="bits">32</width>
<clock units="Hz">66000000</clock>
<configuration>
<setting id="latency" value="64" />
<setting id="maxlatency" value="255" />
<setting id="mingnt" value="4" />
</configuration>
<capabilities>
<capability id="pm" >Power Management</capability>
<capability id="agp" >AGP</capability>
<capability id="agp-2.0" >AGP 2.0</capability>
<capability id="vga_controller" />
<capability id="bus_master" >bus mastering</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
</capabilities>
<resources>
<resource type="memory" value="eb000000-eb07ffff" />
<resource type="memory" value="e0000000-e7ffffff" />
<resource type="memory" value="ea000000-ea00ffff" />
</resources>
</node>
</node>
<node id="usb:0" claimed="true" class="bus" handle="PCI:0000:00:10.0">
<description>USB controller</description>
<product>VT82xxxxx UHCI USB 1.1 Controller [1106:3038]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>10</physid>
<businfo>pci@0000:00:10.0</businfo>
<version>80</version>
<width units="bits">32</width>
<clock units="Hz">33000000</clock>
<configuration>
<setting id="driver" value="uhci_hcd" />
<setting id="latency" value="32" />
</configuration>
<capabilities>
<capability id="pm" >Power Management</capability>
<capability id="uhci" >Universal Host Controller Interface
(USB1)</capability>
<capability id="bus_master" >bus mastering</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
</capabilities>
<resources>
<resource type="irq" value="21" />
<resource type="ioport" value="d000(size=32)" />
</resources>
<node id="usbhost" claimed="true" class="bus" handle="USB:1:1">
<product>UHCI Host Controller [1D6B:1]</product>
<vendor>Linux 3.16.0-4-586 uhci_hcd [1D6B]</vendor>
<physid>1</physid>
<businfo>usb@1</businfo>
<logicalname>usb1</logicalname>
<version>3.16</version>
<configuration>
<setting id="driver" value="hub" />
<setting id="slots" value="2" />
<setting id="speed" value="12Mbit/s" />
</configuration>
<capabilities>
<capability id="usb-1.10" >USB 1.1</capability>
</capabilities>
<node id="usb" claimed="true" class="input" handle="USB:1:2">
<description>Mouse</description>
<product>Basic Optical Mouse [45E:83]</product>
<vendor>Microsoft [45E]</vendor>
<physid>2</physid>
<businfo>usb@1:2</businfo>
<version>0.00</version>
<configuration>
<setting id="driver" value="usbhid" />
<setting id="maxpower" value="100mA" />
<setting id="speed" value="2Mbit/s" />
</configuration>
<capabilities>
<capability id="usb-1.10" >USB 1.1</capability>
</capabilities>
</node>
</node>
</node>
<node id="usb:1" claimed="true" class="bus" handle="PCI:0000:00:10.1">
<description>USB controller</description>
<product>VT82xxxxx UHCI USB 1.1 Controller [1106:3038]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>10.1</physid>
<businfo>pci@0000:00:10.1</businfo>
<version>80</version>
<width units="bits">32</width>
<clock units="Hz">33000000</clock>
<configuration>
<setting id="driver" value="uhci_hcd" />
<setting id="latency" value="32" />
</configuration>
<capabilities>
<capability id="pm" >Power Management</capability>
<capability id="uhci" >Universal Host Controller Interface
(USB1)</capability>
<capability id="bus_master" >bus mastering</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
</capabilities>
<resources>
<resource type="irq" value="21" />
<resource type="ioport" value="d400(size=32)" />
</resources>
<node id="usbhost" claimed="true" class="bus" handle="USB:3:1">
<product>UHCI Host Controller [1D6B:1]</product>
<vendor>Linux 3.16.0-4-586 uhci_hcd [1D6B]</vendor>
<physid>1</physid>
<businfo>usb@3</businfo>
<logicalname>usb3</logicalname>
<version>3.16</version>
<configuration>
<setting id="driver" value="hub" />
<setting id="slots" value="2" />
<setting id="speed" value="12Mbit/s" />
</configuration>
<capabilities>
<capability id="usb-1.10" >USB 1.1</capability>
</capabilities>
</node>
</node>
<node id="usb:2" claimed="true" class="bus" handle="PCI:0000:00:10.2">
<description>USB controller</description>
<product>VT82xxxxx UHCI USB 1.1 Controller [1106:3038]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>10.2</physid>
<businfo>pci@0000:00:10.2</businfo>
<version>80</version>
<width units="bits">32</width>
<clock units="Hz">33000000</clock>
<configuration>
<setting id="driver" value="uhci_hcd" />
<setting id="latency" value="32" />
</configuration>
<capabilities>
<capability id="pm" >Power Management</capability>
<capability id="uhci" >Universal Host Controller Interface
(USB1)</capability>
<capability id="bus_master" >bus mastering</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
</capabilities>
<resources>
<resource type="irq" value="21" />
<resource type="ioport" value="d800(size=32)" />
</resources>
<node id="usbhost" claimed="true" class="bus" handle="USB:4:1">
<product>UHCI Host Controller [1D6B:1]</product>
<vendor>Linux 3.16.0-4-586 uhci_hcd [1D6B]</vendor>
<physid>1</physid>
<businfo>usb@4</businfo>
<logicalname>usb4</logicalname>
<version>3.16</version>
<configuration>
<setting id="driver" value="hub" />
<setting id="slots" value="2" />
<setting id="speed" value="12Mbit/s" />
</configuration>
<capabilities>
<capability id="usb-1.10" >USB 1.1</capability>
</capabilities>
</node>
</node>
<node id="usb:3" claimed="true" class="bus" handle="PCI:0000:00:10.3">
<description>USB controller</description>
<product>USB 2.0 [1106:3104]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>10.3</physid>
<businfo>pci@0000:00:10.3</businfo>
<version>82</version>
<width units="bits">32</width>
<clock units="Hz">33000000</clock>
<configuration>
<setting id="driver" value="ehci-pci" />
<setting id="latency" value="32" />
</configuration>
<capabilities>
<capability id="pm" >Power Management</capability>
<capability id="ehci" >Enhanced Host Controller Interface
(USB2)</capability>
<capability id="bus_master" >bus mastering</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
</capabilities>
<resources>
<resource type="irq" value="21" />
<resource type="memory" value="ec000000-ec0000ff" />
</resources>
<node id="usbhost" claimed="true" class="bus" handle="USB:2:1">
<product>EHCI Host Controller [1D6B:2]</product>
<vendor>Linux 3.16.0-4-586 ehci_hcd [1D6B]</vendor>
<physid>1</physid>
<businfo>usb@2</businfo>
<logicalname>usb2</logicalname>
<version>3.16</version>
<configuration>
<setting id="driver" value="hub" />
<setting id="slots" value="6" />
<setting id="speed" value="480Mbit/s" />
</configuration>
<capabilities>
<capability id="usb-2.00" >USB 2.0</capability>
</capabilities>
</node>
</node>
<node id="isa" claimed="true" class="bridge"
handle="PCI:0000:00:11.0">
<description>ISA bridge</description>
<product>VT8235 ISA Bridge [1106:3177]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>11</physid>
<businfo>pci@0000:00:11.0</businfo>
<version>00</version>
<width units="bits">32</width>
<clock units="Hz">33000000</clock>
<configuration>
<setting id="latency" value="0" />
</configuration>
<capabilities>
<capability id="isa" />
<capability id="pm" >Power Management</capability>
<capability id="bus_master" >bus mastering</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
</capabilities>
</node>
<node id="ide" claimed="true" class="storage"
handle="PCI:0000:00:11.1">
<description>IDE interface</description>
<product>VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE
[1106:571]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>11.1</physid>
<businfo>pci@0000:00:11.1</businfo>
<version>06</version>
<width units="bits">32</width>
<clock units="Hz">33000000</clock>
<configuration>
<setting id="driver" value="pata_via" />
<setting id="latency" value="32" />
</configuration>
<capabilities>
<capability id="ide" />
<capability id="pm" >Power Management</capability>
<capability id="bus_master" >bus mastering</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
</capabilities>
<resources>
<resource type="irq" value="20" />
<resource type="ioport" value="1f0(size=8)" />
<resource type="ioport" value="3f6" />
<resource type="ioport" value="170(size=8)" />
<resource type="ioport" value="376" />
<resource type="ioport" value="dc00(size=16)" />
</resources>
</node>
<node id="multimedia" claimed="true" class="multimedia"
handle="PCI:0000:00:11.5">
<description>Multimedia audio controller</description>
<product>VT8233/A/8235/8237 AC97 Audio Controller
[1106:3059]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>11.5</physid>
<businfo>pci@0000:00:11.5</businfo>
<version>50</version>
<width units="bits">32</width>
<clock units="Hz">33000000</clock>
<configuration>
<setting id="driver" value="snd_via82xx" />
<setting id="latency" value="0" />
</configuration>
<capabilities>
<capability id="pm" >Power Management</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
</capabilities>
<resources>
<resource type="irq" value="22" />
<resource type="ioport" value="e000(size=256)" />
</resources>
</node>
<node id="network" claimed="true" class="network"
handle="PCI:0000:00:12.0">
<description>Ethernet interface</description>
<product>VT6102 [Rhine-II] [1106:3065]</product>
<vendor>VIA Technologies, Inc. [1106]</vendor>
<physid>12</physid>
<businfo>pci@0000:00:12.0</businfo>
<logicalname>eth0</logicalname>
<version>74</version>
<serial>00:0c:76:8e:f0:fd</serial>
<size units="bit/s">100000000</size>
<capacity>100000000</capacity>
<width units="bits">32</width>
<clock units="Hz">33000000</clock>
<configuration>
<setting id="autonegotiation" value="on" />
<setting id="broadcast" value="yes" />
<setting id="driver" value="via-rhine" />
<setting id="driverversion" value="1.5.1" />
<setting id="duplex" value="full" />
<setting id="ip" value="192.168.1.4" />
<setting id="latency" value="32" />
<setting id="link" value="yes" />
<setting id="maxlatency" value="8" />
<setting id="mingnt" value="3" />
<setting id="multicast" value="yes" />
<setting id="port" value="MII" />
<setting id="speed" value="100Mbit/s" />
</configuration>
<capabilities>
<capability id="pm" >Power Management</capability>
<capability id="bus_master" >bus mastering</capability>
<capability id="cap_list" >PCI capabilities listing</capability>
<capability id="ethernet" />
<capability id="physical" >Physical interface</capability>
<capability id="tp" >twisted pair</capability>
<capability id="mii" >Media Independent Interface</capability>
<capability id="10bt" >10Mbit/s</capability>
<capability id="10bt-fd" >10Mbit/s (full duplex)</capability>
<capability id="100bt" >100Mbit/s</capability>
<capability id="100bt-fd" >100Mbit/s (full duplex)</capability>
<capability id="autonegotiation" >Auto-negotiation</capability>
</capabilities>
<resources>
<resource type="irq" value="23" />
<resource type="ioport" value="e400(size=256)" />
<resource type="memory" value="ec001000-ec0010ff" />
</resources>
</node>
</node>
<node id="scsi:0" claimed="true" class="storage" handle="">
<physid>2</physid>
<logicalname>scsi0</logicalname>
<capabilities>
<capability id="emulated" >Emulated device</capability>
</capabilities>
<node id="disk" claimed="true" class="disk" handle="SCSI:00:00:00:00">
<description>ATA Disk</description>
<product>ST340014A</product>
<vendor>Seagate</vendor>
<physid>0.0.0</physid>
<businfo>scsi@0:0.0.0</businfo>
<logicalname>/dev/sda</logicalname>
<dev>8:0</dev>
<version>3.06</version>
<serial>5JX73XSR</serial>
<size units="bytes">40020664320</size>
<configuration>
<setting id="ansiversion" value="5" />
<setting id="logicalsectorsize" value="512" />
<setting id="sectorsize" value="512" />
<setting id="signature" value="4d3ef648" />
</configuration>
<capabilities>
<capability id="partitioned" >Partitioned disk</capability>
<capability id="partitioned:dos" >MS-DOS partition
table</capability>
</capabilities>
<node id="volume:0" claimed="true" class="volume" handle="">
<description>Windows NTFS volume</description>
<physid>1</physid>
<businfo>scsi@0:0.0.0,1</businfo>
<logicalname>/dev/sda1</logicalname>
<dev>8:1</dev>
<version>3.1</version>
<serial>de9c8852-4940-544b-8699-ae2047d3b2e8</serial>
<size units="bytes">29999964672</size>
<capacity>30000000000</capacity>
<configuration>
<setting id="clustersize" value="4096" />
<setting id="created" value="2004-03-03 19:18:55" />
<setting id="filesystem" value="ntfs" />
<setting id="label" value="" />
<setting id="modified_by_chkdsk" value="true" />
<setting id="mounted_on_nt4" value="true" />
<setting id="resize_log_file" value="true" />
<setting id="state" value="dirty" />
<setting id="upgrade_on_mount" value="true" />
</configuration>
<capabilities>
<capability id="primary" >Primary partition</capability>
<capability id="bootable" >Bootable partition
(active)</capability>
<capability id="ntfs" >Windows NTFS</capability>
<capability id="initialized" >initialized volume</capability>
</capabilities>
</node>
<node id="volume:1" claimed="true" class="volume" handle="">
<description>Extended partition</description>
<physid>2</physid>
<businfo>scsi@0:0.0.0,2</businfo>
<logicalname>/dev/sda2</logicalname>
<dev>8:2</dev>
<size units="bytes">10019144704</size>
<capacity>10019144704</capacity>
<capabilities>
<capability id="primary" >Primary partition</capability>
<capability id="extended" >Extended partition</capability>
<capability id="partitioned" >Partitioned disk</capability>
<capability id="partitioned:extended" >Extended
partition</capability>
</capabilities>
<node id="logicalvolume:0" claimed="true" class="volume"
handle="">
<description>Linux filesystem partition</description>
<physid>5</physid>
<logicalname>/dev/sda5</logicalname>
<logicalname>/</logicalname>
<dev>8:5</dev>
<capacity>9557770240</capacity>
<configuration>
<setting id="mount.fstype" value="ext4" />
<setting id="mount.options"
value="rw,relatime,errors=remount-ro,data=ordered" />
<setting id="state" value="mounted" />
</configuration>
</node>
<node id="logicalvolume:1" claimed="true" class="volume"
handle="">
<description>Linux swap / Solaris partition</description>
<physid>6</physid>
<logicalname>/dev/sda6</logicalname>
<dev>8:6</dev>
<capacity>460324864</capacity>
<capabilities>
<capability id="nofs" >No filesystem</capability>
</capabilities>
</node>
</node>
</node>
</node>
<node id="scsi:1" claimed="true" class="storage" handle="">
<physid>3</physid>
<logicalname>scsi1</logicalname>
<capabilities>
<capability id="emulated" >Emulated device</capability>
</capabilities>
<node id="cdrom" claimed="true" class="disk"
handle="SCSI:01:00:00:00">
<description>DVD reader</description>
<product>COMBO LTC-48161H</product>
<vendor>LITE-ON</vendor>
<physid>0.0.0</physid>
<businfo>scsi@1:0.0.0</businfo>
<logicalname>/dev/cdrom</logicalname>
<logicalname>/dev/cdrw</logicalname>
<logicalname>/dev/dvd</logicalname>
<logicalname>/dev/sr0</logicalname>
<logicalname>/media/cdrom0</logicalname>
<dev>11:0</dev>
<version>KH0P</version>
<configuration>
<setting id="ansiversion" value="5" />
<setting id="mount.fstype" value="iso9660" />
<setting id="mount.options"
value="ro,nosuid,nodev,noexec,relatime" />
<setting id="state" value="mounted" />
<setting id="status" value="ready" />
</configuration>
<capabilities>
<capability id="removable" >support is removable</capability>
<capability id="audio" >Audio CD playback</capability>
<capability id="cd-r" >CD-R burning</capability>
<capability id="cd-rw" >CD-RW burning</capability>
<capability id="dvd" >DVD playback</capability>
</capabilities>
<node id="medium" claimed="true" class="disk" handle="">
<physid>0</physid>
<logicalname>/dev/cdrom</logicalname>
<logicalname>/media/cdrom0</logicalname>
<dev>11:0</dev>
<configuration>
<setting id="mount.fstype" value="iso9660" />
<setting id="mount.options"
value="ro,nosuid,nodev,noexec,relatime" />
<setting id="state" value="mounted" />
</configuration>
</node>
</node>
</node>
</node>
</node>
</list>
---- end of lshw xml file --------
--
"The most violent element in society is ignorance" rEG
"Who died and made you the superuser?" Brooklinux
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.debian.user
csiph-web