Bug#987845: hardwired proxy settings by debian-installer with network-auto-config in proxy-auto-config network

2021-05-02 Thread Rado S
=- Geert Stappers wrote on Fri 30.Apr'21 at 22:04:09 +0200 -=

> On Fri, Apr 30, 2021 at 09:25:47PM +0200, Rado Q wrote:
> > Installation network setup was auto-configured while the system was
> > in a network with proxy-auto-config active.
> > 
> > Expectation:
> > when choosing auto-configure-network during installation, the
> > resulting system should be operative in every foreign environment.
> > (think of notebook in roaming use)
> > 
> > Result:
> > applications strictly following those hardwired configs can't operate
> > outside the original installation network, where the given proxy exists,
> > but nowhere else. PAC results during installation shouldn't be
> > 'hardwired' into the system to last when moving to another network.
> 
> Acknowledge on the problem.
> 
> Which possible solutions do we see?

How about having a boot process check for the network strategy
(fixed or dhcp), and if dhcp, let it discover the proxy by WPAD/PAC
and store it in /var/run, and have general config include it from
there, if it exists, like:

/etc/profile.d/proxy-check:

DYNPROXYCFG=/var/run/proxy-cfg
if [ -s "$DYNPROXYCFG" ]
then
. "$DYNPROXYCFG"
fi

Everything else not respecting those http_proxy vars would need
similar stuff. APT seems to have its own PAC features, which could/
should be used instead of storing fixed values, or use the same as
above (if APT/itude works with those http_proxy vars).

Rado



Bug#942208: Login GUI build up & interaction in slow motion (2-3secs to complete)

2020-07-16 Thread Rado S
Finally I figured it out. Using the intel-driver made it smooth &
fast again as it used to be on this hardware. I had to add this:

>> /usr/share/X11/xorg.conf.d/99-intel.conf'

-- QUOTE BEGIN --
Section "Device"
Identifier "Intel"
Driver "intel"
#   Option "AccelMethod" "uxa"
EndSection 
--- QUOTE END ---

Sooo, the "default" driver "glamor" does not work well with
Intel GM45 Express Chipset x86/MMX/SSE2.

Please adjust the support or make it use the intel driver instead.

Thank you,
Rado,
 enjoy



Bug#942219: systemd-backlight@backlight:dell_backlight.service fails at boot for dell d600, d620, d820

2019-10-17 Thread Rado S
=- Michael Biebl wrote on Wed 16.Oct'19 at 13:06:29 +0200 -=

> >>> # cat /sys/class/backlight/intel_backlight/brightness
> >>> 1500
> > 
> > I get 79560.
> > 
> >> and change it via
> >>> # echo 2000 > /sys/class/backlight/intel_backlight/brightness
> > 
> > Setting it via intel to 6 makes it darker.
> > 
> >> What's the output you get for your dell_backlight?
> > 
> >>From dell_backlight I get:
> > # cat dell_backlight/brightness
> > 6
> > 
> > But when setting it, it says:
> > 
> > # echo 5 > dell_backlight/brightness
> > -ksh: echo: write to 1 failed [Input/output error]
> > {...}
> > What next?
> 
> Dunno. You'll probably need to ask someone who is familiar with
> Dell hardware. I have no idea why these Dell laptops provide a
> dell_backlight device and what this device supposed to control.
> Apparently it can't be used to change the brightness despite it
> exposing the brightness attribute.

For the record:
the dell value for brightness reflects the scale given in the BIOS
menu: (0-7)

The dell vostro works OK:
despite having an Intel GM45 it has no intel_backlight device at
the same place as the others.
Instead it has acpi_video0 which scales like the dell_backlight
(values 0-7) rather than the intel_backlight (*1000).
At Installation time xorg also decided not to use a gpu specific
driver (xorg-video-intel) with the vostro for the acpi_video0, which
in return made X operate slow compared to the older dells, which
still do use the xorg-video-intel (or radeon).

Which components of the installer decide whether to use xorg-drivers
and which devices to create for backlight handling?

Is this still systemd or again a kernel issue?

Thanks for your support so far,
Rado



Bug#942219: systemd-backlight@backlight:dell_backlight.service fails at boot for dell d600, d620, d820

2019-10-15 Thread Rado S
=- Michael Biebl wrote on Tue 15.Oct'19 at 13:33:15 +0200 -=

> I can get the current brightness via
> > # cat /sys/class/backlight/intel_backlight/brightness
> > 1500

I get 79560.

> and change it via
> > # echo 2000 > /sys/class/backlight/intel_backlight/brightness

Setting it via intel to 6 makes it darker.

> What's the output you get for your dell_backlight?

>From dell_backlight I get:
# cat dell_backlight/brightness
6

But when setting it, it says:

# echo 5 > dell_backlight/brightness
-ksh: echo: write to 1 failed [Input/output error]

This is what both links look like:

0 lrwxrwxrwx 1 root root 0 Oct 16 05:01 dell_backlight -> 
../../devices/platform/dell-laptop/backlight/dell_backlight/
0 lrwxrwxrwx 1 root root 0 Oct 16 04:54 intel_backlight -> 
../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/

dell_backlight/:
total 0
0 -r--r--r-- 1 root root 4096 Oct 16 05:03 actual_brightness
0 -rw-r--r-- 1 root root 4096 Oct 16 05:03 bl_power
0 -rw-r--r-- 1 root root 4096 Oct 16 05:04 brightness
0 lrwxrwxrwx 1 root root0 Oct 16 05:03 device -> ../../../dell-laptop/
0 -r--r--r-- 1 root root 4096 Oct 16 05:03 max_brightness
0 drwxr-xr-x 2 root root0 Oct 16 05:03 power/
0 lrwxrwxrwx 1 root root0 Oct 16 04:52 subsystem -> 
../../../../../class/backlight/
0 -r--r--r-- 1 root root 4096 Oct 16 05:03 type
0 -rw-r--r-- 1 root root 4096 Oct 16 05:03 uevent

intel_backlight/:
total 0
0 -r--r--r-- 1 root root 4096 Oct 16 04:54 actual_brightness
0 -rw-r--r-- 1 root root 4096 Oct 16 04:54 bl_power
0 -rw-r--r-- 1 root root 4096 Oct 16 04:54 brightness
0 lrwxrwxrwx 1 root root0 Oct 16 04:54 device -> ../../card0-LVDS-1/
0 -r--r--r-- 1 root root 4096 Oct 16 04:54 max_brightness
0 drwxr-xr-x 2 root root0 Oct 16 04:54 power/
0 lrwxrwxrwx 1 root root0 Oct 16 04:54 subsystem -> 
../../../../../../../class/backlight/
0 -r--r--r-- 1 root root 4096 Oct 16 04:54 type
0 -rw-r--r-- 1 root root 4096 Oct 16 04:54 uevent

What next?



Bug#942219: systemd-backlight@backlight:dell_backlight.service fails at boot for dell d600, d620, d820

2019-10-14 Thread Rado S
=- Michael Biebl wrote on Mon 14.Oct'19 at 23:20:57 +0200 -=

> Am 14.10.19 um 23:13 schrieb Rado S:
> > dell_backlight: Failed to write system 'brightness' attribute: No such 
> > device or address
> 
> Looks like a kernel or firmware/bios problem to me.
> 
> Since you didn't use reportbug there is no information about your used
> kernel.

It is in the journalctl output;
Linux version 4.19.0-6-686-pae (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28)

The dell d600 (also failing) uses the non-pae version of it.
The functioning vostro uses the same pae-version.

What more information can I provide?



Bug#942219: systemd-backlight@backlight:dell_backlight.service fails at boot for dell d600, d620, d820

2019-10-14 Thread Rado S
=- Michael Biebl wrote on Sun 13.Oct'19 at 21:28:08 +0200 -=

> Please attach the output of (run as root)
> systemctl status systemd-backlight@backlight:dell_backlight.service
> journalctl -alb

See attachment.
Do you need it from the other failing systems or is this one sufficient?

Rado
● systemd-backlight@backlight:dell_backlight.service - Load/Save Screen 
Backlight Brightness of backlight:dell_backlight
   Loaded: loaded (/etc/systemd/system/systemd-backlight@.service; static; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-10-14 23:04:45 CEST; 1min 
15s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 291 ExecStart=/lib/systemd/systemd-backlight load 
backlight:dell_backlight (code=exited, status=1/FAILURE)
 Main PID: 291 (code=exited, status=1/FAILURE)

Oct 14 23:04:45 sam320 systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:dell_backlight...
Oct 14 23:04:45 sam320 systemd-backlight[291]: dell_backlight: Failed to write 
system 'brightness' attribute: No such device or address
Oct 14 23:04:45 sam320 systemd[1]: 
systemd-backlight@backlight:dell_backlight.service: Main process exited, 
code=exited, status=1/FAILURE
Oct 14 23:04:45 sam320 systemd[1]: 
systemd-backlight@backlight:dell_backlight.service: Failed with result 
'exit-code'.
Oct 14 23:04:45 sam320 systemd[1]: Failed to start Load/Save Screen Backlight 
Brightness of backlight:dell_backlight.
-- Logs begin at Mon 2019-10-14 23:04:42 CEST, end at Mon 2019-10-14 23:06:24 
CEST. --
Oct 14 23:04:42 sam320 kernel: Linux version 4.19.0-6-686-pae 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP 
Debian 4.19.67-2 (2019-08-28)
Oct 14 23:04:42 sam320 kernel: Disabled fast string operations
Oct 14 23:04:42 sam320 kernel: x86/fpu: x87 FPU will use FXSAVE
Oct 14 23:04:42 sam320 kernel: BIOS-provided physical RAM map:
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0x-0x0009efff] usable
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0x0009f000-0x0009] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0x0010-0xbf6813ff] usable
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xbf681400-0xbfff] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xf000-0xf4006fff] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xf4008000-0xf400bfff] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xfec0-0xfec0] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xfed2-0xfed9] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xfee0-0xfee0] reserved
Oct 14 23:04:42 sam320 kernel: BIOS-e820: [mem 
0xffb0-0x] reserved
Oct 14 23:04:42 sam320 kernel: NX (Execute Disable) protection: active
Oct 14 23:04:42 sam320 kernel: SMBIOS 2.4 present.
Oct 14 23:04:42 sam320 kernel: DMI: Dell Inc. Latitude D620   
/0TD761, BIOS A10 05/16/2008
Oct 14 23:04:42 sam320 kernel: tsc: Fast TSC calibration using PIT
Oct 14 23:04:42 sam320 kernel: tsc: Detected 1830.830 MHz processor
Oct 14 23:04:42 sam320 kernel: e820: update [mem 0x-0x0fff] usable 
==> reserved
Oct 14 23:04:42 sam320 kernel: e820: remove [mem 0x000a-0x000f] usable
Oct 14 23:04:42 sam320 kernel: last_pfn = 0xbf681 max_arch_pfn = 0x100
Oct 14 23:04:42 sam320 kernel: MTRR default type: uncachable
Oct 14 23:04:42 sam320 kernel: MTRR fixed ranges enabled:
Oct 14 23:04:42 sam320 kernel:   0-9 write-back
Oct 14 23:04:42 sam320 kernel:   A-B uncachable
Oct 14 23:04:42 sam320 kernel:   C-C write-protect
Oct 14 23:04:42 sam320 kernel:   D-E uncachable
Oct 14 23:04:42 sam320 kernel:   F-F write-protect
Oct 14 23:04:42 sam320 kernel: MTRR variable ranges enabled:
Oct 14 23:04:42 sam320 kernel:   0 base 0 mask F8000 write-back
Oct 14 23:04:42 sam320 kernel:   1 base 08000 mask FC000 write-back
Oct 14 23:04:42 sam320 kernel:   2 base 0BF80 mask FFF80 uncachable
Oct 14 23:04:42 sam320 kernel:   3 base 0BF70 mask 0 uncachable
Oct 14 23:04:42 sam320 kernel:   4 disabled
Oct 14 23:04:42 sam320 kernel:   5 disabled
Oct 14 23:04:42 sam320 kernel:   6 disabled
Oct 14 23:04:42 sam320 kernel:   7 disabled
Oct 14 23:04:42 sam320 kernel: x86/PAT: PAT not supported by CPU.
Oct 14 23:04:42 sam320 kernel: x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB 
 WT  UC- UC  
Oct 14 23:04:42 sam320 kernel: initial memory mapped: [mem 
0x-0x16ff]
Oct 14 23:04:42 sam320 kernel: BRK [0x16b6e000, 0x16b6efff] PGTABLE
Oct 14 23:04:42 sam320 kernel: BRK [0x16b6f000, 0x16b70fff] PGTABLE
Oct 14 23:04:42 sam320 kernel: BRK [0x16b71000, 0x16b71fff] PGTABLE
Oct 14 23:04:42 sam320 kernel: BRK [0x16b72000, 0x16b72fff] PGTABLE
Oct 14 23:04:42 sam320 kernel: RAMDISK: [mem 0x35763000-0x36ba8fff]
Oct 14 23

Bug#941239: poweroff+reboot stalls/freezes after "Reached target poweroff" instead of actually turning poweroff

2019-10-12 Thread Rado S
=- Michael Biebl wrote on Sat  5.Oct'19 at 12:44:14 +0200 -=

> Control: reassign -1 linux-image-4.19.0-6-686
> 
> It looks like a kernel indeed with the information you've provided
> so far. So reassigning the bug report.

Summary update:

shutdown fails 99%, reboot once in a while (maybe 20-30%) for
- single core
- non-pae
- 2GB RAM
(dell d600, d800)

shutdown & reboot NEVER fail for
- dual core
- pae
- 4 GB RAM
(dell d620, d820, vostro1520)

All of them 32bit



Bug#941239: systemd 241-7, poweroff+reboot stalls/freezes after "Reached target shutdown"

2019-10-04 Thread Rado S
=- Michael Biebl wrote on Thu  3.Oct'19 at 13:51:28 +0200 -=

> > How to find more information on this failure?
> 
> Do you get any shutdown messages from systemd when you shut down?

No, the screen is black all the time except for the initally
blinking but eventually frozen cursor in top-left corner.
Even after disabling xdm, therefore having only the vt1-6, this
doesn't change.
Maybe I have to configure something to make the shutdown messages appear?

I can't recall how/ when, maybe it was with debian9, but _once_ I
_have_ seen this "Reached target shutdown" frozen as well on vt1
after all the other shutdown messages.
Or maybe I can log those to a file, too?

> Please also follow the hints in
> /usr/share/doc/systemd/README.Debian.gz (Debugging boot/shutdown problems)
> 
> See the section starting with "In situations where the debug shell is
> not available,..."

I've attached the so produced log-file.

During reboot for providing this log (which didn't freeze this time by
chance), the inserted PC(mcia) Card's "Link" light indicator and the
notebook's display lose electrical power, while both keep electrical
power on in the stuck shutdown.

What else can I do?

Thanks,
Rado
[0.00] Linux version 4.19.0-6-686 (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28)
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7ffadfff] usable
[0.00] BIOS-e820: [mem 0x7ffae000-0x7fff] reserved
[0.00] BIOS-e820: [mem 0xfeda-0xfedf] reserved
[0.00] BIOS-e820: [mem 0xffb0-0x] reserved
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] SMBIOS 2.3 present.
[0.00] DMI: Dell Computer Corporation Latitude D600   
/0X2034, BIOS A16 06/29/2005
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 1398.716 MHz processor
[0.008167] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.008174] e820: remove [mem 0x000a-0x000f] usable
[0.008184] last_pfn = 0x7ffae max_arch_pfn = 0x10
[0.008196] MTRR default type: uncachable
[0.008199] MTRR fixed ranges enabled:
[0.008202]   0-9 write-back
[0.008204]   A-B uncachable
[0.008206]   C-C write-protect
[0.008209]   D-E uncachable
[0.008211]   F-F write-protect
[0.008213] MTRR variable ranges enabled:
[0.008216]   0 base 0 mask F8000 write-back
[0.008219]   1 base 0FEDA mask E write-through
[0.008220]   2 disabled
[0.008222]   3 disabled
[0.008223]   4 disabled
[0.008225]   5 disabled
[0.008226]   6 disabled
[0.008228]   7 disabled
[0.009519] x86/PAT: PAT not supported by CPU.
[0.009681] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UC  
[0.059652] initial memory mapped: [mem 0x-0x06ff]
[0.059738] BRK [0x06a93000, 0x06a93fff] PGTABLE
[0.059791] RAMDISK: [mem 0x35501000-0x36a77fff]
[0.059810] ACPI: Early table checksum verification disabled
[0.066467] ACPI: RSDP 0x000FDF00 14 (v00 DELL  )
[0.066475] ACPI: RSDT 0x7FFF 2C (v01 DELL   CPi R
27D5061D ASL  0061)
[0.066487] ACPI: FACP 0x7FFF0400 74 (v01 DELL   CPi R
27D5061D ASL  0061)
[0.066500] ACPI: DSDT 0x7FFF0C00 002E1A (v01 INT430 SYSFexxx 
1001 MSFT 010E)
[0.066508] ACPI: FACS 0x7800 40
[0.066514] ACPI: ASF! 0x7FFF0800 5B (v16 DELL   CPi R
27D5061D ASL  0061)
[0.066555] 1171MB HIGHMEM available.
[0.066557] 875MB LOWMEM available.
[0.066559]   mapped low ram: 0 - 36bfe000
[0.066561]   low ram: 0 - 36bfe000
[0.066574] BRK [0x06a94000, 0x06a94fff] PGTABLE
[0.066579] Zone ranges:
[0.066580]   DMA  [mem 0x1000-0x00ff]
[0.066584]   Normal   [mem 0x0100-0x36bfdfff]
[0.066587]   HighMem  [mem 0x36bfe000-0x7ffadfff]
[0.066590] Movable zone start for each node
[0.066592] Early memory node ranges
[0.066594]   node   0: [mem 0x1000-0x0009efff]
[0.066596]   node   0: [mem 0x0010-0x7ffadfff]
[0.066599] Initmem setup node 0 [mem 0x1000-0x7ffadfff]
[0.066603] On node 0 totalpages: 524108
[0.097602]   DMA zone: 40 pages used for memmap
[0.097605]   DMA zone: 0 pages reserved
[0.097607]   DMA zone: 3998 pages, LIFO batch:0
[0.097983]   Normal zone: 2150 pages used for memmap
[0.097986]   Normal zone: 220158 pages, LIFO batch:63
[  

Bug#717096: not amavis' fault, but file magic

2017-06-22 Thread Rado S
=- Henrique de Moraes Holschuh wrote on Tue 20.Jun'17 at 13:23:16 -0300 -=

> Do you guys have any idea of which version of "file" magic causes
> trouble?

I don't know when it starts to break, but this one fails:

magic binary file for file(1) cmd (version 7) (little endian)



Bug#686611: xserver-xorg-video-nouveau: Distorted graphics with GeForce 4200Go (NV28)

2015-06-27 Thread Rado S
=- To Debian Bug Tracking System wrote on Sat 27.Jun'15 at 14:42:45 +0200 -=

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.11-1
> Followup-For: Bug #686611

Ooops, sorry, I used "reportbug", didn't notice #595477, and it
didn't mention #686611 was merged with it.

Shall I re-report to #595477?

Rado


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org