Next Kernel update for Buster

2020-07-28 Thread gianluca

Hello,
I was wondering if there is any chance to have a better kernel from the 
4.19.129 or greater.


I am asking this, mainly because of the BUG correction on NILFS2 Garbage 
Collector as my systems are using NILFS2 as rootfs and at the moment 
they are unable to boot off a nilfs2-formatted disk.


Have a look at: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/nilfs2?h=v4.19.129=1b6f42200b8313d3895c26f6553bbc8380bf1c35



At the moment the only workaround I have found is using an 
ext4-formatted disk, but it is merely temporary.


Best regards,
Gianluca Renzi
--
Eurek s.r.l.  |
Electronic Engineering| http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212



Re: Next Kernel update for Buster

2020-07-28 Thread gianluca

On 7/28/20 3:35 PM, Salvatore Bonaccorso wrote:


Have a look at: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/nilfs2?h=v4.19.129=1b6f42200b8313d3895c26f6553bbc8380bf1c35


The next point release for buster (10.5) will contain an update of
src:linux to 4.19.132, see
https://lists.debian.org/debian-stable-announce/2020/07/msg1.html


that's a very good news to know. What about timeline for 10.5??
;-)

Regards,
--
Eurek s.r.l.  |
Electronic Engineering| http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212



Bug#775178: linux-image-3.2.0-4-amd64: linux-image-3.2.0-4-amd64: regression: suspend/resume not working after update (again)

2015-01-13 Thread Gianluca Bonetti
Package: src:linux
Version: 3.2.65-1
Followup-For: Bug #775178

Dear Maintainer,

I confirm the regression of linux kernel 3.2.65-1
The previous kernel, version 3.2.63-2+deb7u2 from wheezy-backports,
run always fine.
After upgrading from backports 3.2.63-2+deb7u2 to official 3.2.65-1,
my notebook freezes every time it comes back from suspend.
This also caused some minor data corruption.
Reverting back to backports 3.2.63-2+deb7u2 fixes the bug!

I can reproduce this bug EVERY TIME.
It only takes to put in suspend, then resume.
The PC freezes and does not respond to ping on network.

This is a portion of my /var/log/syslog
I put the notebook in suspend at 04:03 am and resumed at 10:32 am
No signal that it has come back to resume at 10:32, but I did so.
Then I had to reboot the system.

...
Jan 13 04:03:11 localhost kernel: [24542.738421] wlan0:
deauthenticating from 08:60:6e:cc:a3:38 by local choice (reason=3)
Jan 13 04:03:11 localhost wpa_supplicant[2736]: wlan0:
CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
Jan 13 04:03:11 localhost kernel: [24542.850948] cfg80211: Calling
CRDA to update world regulatory domain
Jan 13 04:03:11 localhost NetworkManager[2622]: info (wlan0): cleaning up...
Jan 13 04:03:11 localhost NetworkManager[2622]: info (wlan0): taking
down device.
Jan 13 04:03:11 localhost dbus[2498]: [system] Activating service
name='org.freedesktop.nm_dispatcher' (using servicehelper)
Jan 13 04:03:12 localhost kernel: [24543.398136] cfg80211: World
regulatory domain updated:
Jan 13 04:03:12 localhost kernel: [24543.398139] cfg80211:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jan 13 04:03:12 localhost kernel: [24543.398142] cfg80211:
(2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm)
Jan 13 04:03:12 localhost kernel: [24543.398145] cfg80211:
(2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm)
Jan 13 04:03:12 localhost kernel: [24543.398147] cfg80211:
(2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm)
Jan 13 04:03:12 localhost kernel: [24543.398148] cfg80211:
(517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 mBm)
Jan 13 04:03:12 localhost kernel: [24543.398150] cfg80211:
(525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 mBm)
Jan 13 04:03:12 localhost kernel: [24543.398152] cfg80211:
(549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm)
Jan 13 04:03:12 localhost kernel: [24543.398154] cfg80211:
(5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm)
Jan 13 04:03:12 localhost kernel: [24543.398156] cfg80211:
(5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm)
Jan 13 04:03:12 localhost dbus[2498]: [system] Successfully activated
service 'org.freedesktop.nm_dispatcher'
Jan 13 10:32:48 localhost kernel: imklog 5.8.11, log source =
/proc/kmsg started.
Jan 13 10:32:48 localhost rsyslogd: [origin software=rsyslogd
swVersion=5.8.11 x-pid=2204 x-info=http://www.rsyslog.com;] start
...

Please fix the bug.
Thank you
Best regards
Gianluca Bonetti

-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc
version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.65-1

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=/dev/sda1 ro quiet splash

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[6.235713] uvcvideo: Please report required quirks to the
linux-uvc-devel mailing list.
[6.242396] input: FJ Camera as
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input10
[6.242486] usbcore: registered new interface driver uvcvideo
[6.242488] USB Video Class driver (1.1.1)
[6.286606] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
[6.286610] Copyright(c) 2003-2011 Intel Corporation
[6.28] iwlwifi :08:00.0: setting latency timer to 64
[6.286695] iwlwifi :08:00.0: pci_resource_len = 0x2000
[6.286699] iwlwifi :08:00.0: pci_resource_base = c900050b4000
[6.286701] iwlwifi :08:00.0: HW Revision ID = 0xC4
[6.286778] iwlwifi :08:00.0: irq 44 for MSI/MSI-X
[6.286812] iwlwifi :08:00.0: Detected 2000 Series 2x2 BGN/BT, REV=0xC8
[6.286868] iwlwifi :08:00.0: L1 Disabled; Enabling L0S
[6.303483] iwlwifi :08:00.0: device EEPROM VER=0x81c, CALIB=0x6
[6.303485] iwlwifi :08:00.0: Device SKU: 0X150
[6.303487] iwlwifi :08:00.0: Valid Tx ant: 0X3, Valid Rx ant: 0X3
[6.303505] iwlwifi :08:00.0: Tunable channels: 13 802.11bg, 0
802.11a channels
[6.538492] iwlwifi :08:00.0: firmware: agent loaded
iwlwifi-2030-6.ucode into memory
[6.538501] iwlwifi :08:00.0: loaded firmware version 18.168.6.1
[6.538801] Registered led device: phy0-led
[6.567153] audit: name_count maxed, losing inode data: dev=00:06, inode=8308
[6.567156] audit: name_count maxed, losing inode data: dev=00:06, inode=8308
[6.567159] audit: name_count maxed, losing inode data: dev=00:06, inode=8308
[6.567161] audit: name_count maxed, losing inode data: dev

Re: Issue on using DVB-T USB Stick on Jessie PowerPC64

2015-06-16 Thread Gianluca Renzi
Oops, I forgot the attachment!

On Tue, Jun 16, 2015 at 12:35 PM, Gianluca Renzi icj...@gmail.com wrote:

 Hello list!
 I would like inform you (as Tobias Grimm tobias.gr...@e-tobi.net he is
 the w_scan maintainer for Debian) as suggested to me to look deeper on my
 issue so I decided to explain my issue.

 Here is some information:

 System Machines:
 Apple PowerBook G4 32bit PowerPC Laptop
 Apple Quad Core G5 64bit PowerPC Tower

 On both machines I have the _SAME_ Debian Jessie and the same kernel
 version, and the same version of linux-non-free drivers and the DVB API
 (from debian repos) for the USB dogle DVB-T I am using.

 The G5 Machine has the 64bit version meanwhile the G4 is the 32bit version.

 When connecting the USB Dongle on the G4 I have the same messages I got in
 the G5 machine:

 

 POWERPC 64 Bit G5:

 [ 4559.231333] usb 1-3.5.2: new high-speed USB device number 11 using
 ehci-pci
 [ 4559.327828] usb 1-3.5.2: New USB device found, idVendor=07ca,
 idProduct=850a
 [ 4559.327839] usb 1-3.5.2: New USB device strings: Mfr=1, Product=2,
 SerialNumber=3
 [ 4559.327845] usb 1-3.5.2: Product: A850 DVBT
 [ 4559.327851] usb 1-3.5.2: Manufacturer: AVerMedia
 [ 4559.327857] usb 1-3.5.2: SerialNumber: 302795401381000
 [ 4559.329949] usb 1-3.5.2: dvb_usb_v2: found a 'AverMedia AVerTV Volar
 Black HD (A850)' in cold state
 [ 4559.330042] usb 1-3.5.2: firmware: direct-loading firmware
 dvb-usb-af9015.fw
 [ 4559.330054] usb 1-3.5.2: dvb_usb_v2: downloading firmware from file
 'dvb-usb-af9015.fw'
 [ 4559.403336] usb 1-3.5.2: dvb_usb_v2: found a 'AverMedia AVerTV Volar
 Black HD (A850)' in warm state
 [ 4559.810247] usb 1-3.5.2: dvb_usb_v2: will pass the complete MPEG2
 transport stream to the software demuxer
 [ 4559.811281] DVB: registering new adapter (AverMedia AVerTV Volar Black
 HD (A850))
 [ 4559.812936] i2c i2c-8: af9013: firmware version 4.95.0.0
 [ 4559.817066] usb 1-3.5.2: DVB: registering adapter 0 frontend 0 (Afatech
 AF9013)...
 [ 4559.817298] MXL5005S: Attached at address 0xc6
 [ 4559.828686] usb 1-3.5.2: dvb_usb_v2: 'AverMedia AVerTV Volar Black HD
 (A850)' successfully initialized and connected
 [ 4560.533529] usbcore: registered new interface driver dvb_usb_af9015

 

 POWERPC 32BIT G4:

 [  461.600958] usb 1-2: new high-speed USB device number 3 using ehci-pci
 [  461.737345] usb 1-2: New USB device found, idVendor=07ca, idProduct=850a
 [  461.737361] usb 1-2: New USB device strings: Mfr=1, Product=2,
 SerialNumber=3
 [  461.737370] usb 1-2: Product: A850 DVBT
 [  461.737377] usb 1-2: Manufacturer: AVerMedia
 [  461.737385] usb 1-2: SerialNumber: 302795401381000
 [  463.138837] usb 1-2: dvb_usb_v2: found a 'AverMedia AVerTV Volar Black
 HD (A850)' in cold state
 [  463.158350] usb 1-2: firmware: direct-loading firmware dvb-usb-af9015.fw
 [  463.158373] usb 1-2: dvb_usb_v2: downloading firmware from file
 'dvb-usb-af9015.fw'
 [  463.229316] usb 1-2: dvb_usb_v2: found a 'AverMedia AVerTV Volar Black
 HD (A850)' in warm state
 [  463.631215] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport
 stream to the software demuxer
 [  463.631579] DVB: registering new adapter (AverMedia AVerTV Volar Black
 HD (A850))
 [  463.689604] i2c i2c-8: af9013: firmware version 4.95.0.0
 [  463.692588] usb 1-2: DVB: registering adapter 0 frontend 0 (Afatech
 AF9013)...
 [  463.752256] MXL5005S: Attached at address 0xc6
 [  463.762217] usb 1-2: dvb_usb_v2: 'AverMedia AVerTV Volar Black HD
 (A850)' successfully initialized and connected
 [  463.762356] usbcore: registered new interface driver dvb_usb_af9015

 ---

 Here is the log for G5 (does not work)
 ~$ w_scan -v -v
 w_scan -v -v
 w_scan version 20130331 (compiled for DVB API 5.4)
 WARNING: could not guess your country. Falling back to 'DE'
 guessing country 'DE', use -c country to override
 using settings for GERMANY
 DVB aerial
 DVB-T Europe
 scan type TERRESTRIAL, channellist 4
 output format vdr-2.0
 WARNING: could not guess your codepage. Falling back to 'UTF-8'
 output charset 'UTF-8', use -C charset to override
 Info: using DVB adapter auto detection.
 /dev/dvb/adapter0/frontend0 - Afatech AF9013 doesnt support
 TERRESTRIAL - SEARCH NEXT ONE.
 main:3228: FATAL: * NO USEABLE TERRESTRIAL CARD FOUND. *
 Please check wether dvb driver is loaded and
 verify that no dvb application (i.e. vdr) is running.


 or if I specify the adapter frontend:

 ~$ w_scan -a /dev/dvb/adapter0/frontend0 -v -v
 w_scan version 20130331 (compiled for DVB API 5.4)
 WARNING: could not guess your country. Falling back to 'DE'
 guessing country 'DE', use -c country to override
 using settings for GERMANY
 DVB aerial
 DVB-T Europe
 scan type TERRESTRIAL, channellist 4
 output format vdr-2.0
 WARNING: could not guess your codepage. Falling back to 'UTF-8'
 output charset 'UTF-8', use -C charset to override
 -_-_-_-_ Getting frontend capabilities-_-_-_-_
 main:3244: FATAL: Your

issue for DVB-T Afatech based on LinuxPPC G5 (64bit) but NO issue on PowerPC G4 (32bit)

2015-06-16 Thread Gianluca Renzi
 country. Falling back to 'DE'
guessing country 'DE', use -c country to override
using settings for GERMANY
DVB aerial
DVB-T Europe
scan type TERRESTRIAL, channellist 4
output format vdr-2.0
WARNING: could not guess your codepage. Falling back to 'UTF-8'
output charset 'UTF-8', use -C charset to override
Info: using DVB adapter auto detection.
= Afatech AF9013 ===
len = 1
0x00: 03  :

/dev/dvb/adapter0/frontend0 - TERRESTRIAL Afatech AF9013: good :-)
Using TERRESTRIAL frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_
Using DVB API 5.a
frontend 'Afatech AF9013' supports
INVERSION_AUTO
QAM_AUTO
TRANSMISSION_MODE_AUTO
GUARD_INTERVAL_AUTO
HIERARCHY_AUTO
FEC_AUTO
FREQ (174.00MHz ... 860.00MHz)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
= Afatech AF9013 ===
len = 1
0x00: 03  :

Scanning 7MHz frequencies


I wrote to Tobias and he sent me a simple code to check what version is
running on dvb_core DVB-API (the code is in attachment) and it reports:

POWERPC G4:
$ ./getdvbapiversion /dev/dvb/adapter0/frontend0
DVB-API Version from header files: 5.10 (0x050A)
DVB-API Version from frontend /dev/dvb/adapter0/frontend0: 5.10 (0x050A)


POWERPC G5:
$ ./getdvbapiversion /dev/dvb/adapter0/frontend0
DVB-API Version from header files: 5.10 (0x050A)
Could not query API version from the DVB API

It seems in the POWERPC G5 the legacy ioctl to the FE in general works. It
just seems the new
FE_GET/SET_PROPERTY are not accepted.

It is strange, because on POWERPC G4 works.

Some hint, help or clue??

Best Regards,
Gianluca

-- 
Ciao e buona giornata.

GP! In mezzo al campo stai proprio schifoso!
Coach M.Russo
#include linux/dvb/version.h
#include linux/dvb/frontend.h
#include sys/ioctl.h
#include fcntl.h
#include stdio.h
#include unistd.h


int main(int argc, char *argv[]) {
if (argc  2) {
  printf(Usage: dvbapiversion frontend\n);
  printf(e.g. dvbapiversion /dev/dvb/adapter0/frontend0\n);
  return -1;
}

printf(DVB-API Version from header files: %d.%d (0x%04X)\n, DVB_API_VERSION, DVB_API_VERSION_MINOR, DVB_API_VERSION  8 | DVB_API_VERSION_MINOR);

struct dtv_property prop[] = {
{ .cmd = DTV_API_VERSION },
};
struct dtv_properties props = {
.num = 1,
.props = prop
};

int frontend_fd = open(argv[1], O_RDWR | O_NONBLOCK);
if (frontend_fd  0) {
printf(Can't open frontend %s\n, argv[1]);
return -1;
}

struct dvb_frontend_info frontendInfo;
if (ioctl (frontend_fd, FE_GET_INFO, frontendInfo) = 0) {
   printf(Frontend name: %s\n, frontendInfo.name);
}
else {
   printf(Could not query frontend info from the DVB API\n);
}


if (ioctl (frontend_fd, FE_GET_PROPERTY, props) = 0) {
   printf(DVB-API Version from frontend %s: %d.%d (0x%04X)\n, argv[1], prop[0].u.data  8,  prop[0].u.data  0xFF, prop[0].u.data);
}
else {
   printf(Could not query API version from the DVB API\n);
}

close(frontend_fd);

return 0;
}


Bug#792913: Package: linux-image-4.0.0-2-amd64

2015-07-20 Thread Gianluca Renzi
Same here in PowerPC G5 Quad Core with ATI Radeon HD4670 and NVidia 6600.
The first is not loading Xorg, the latter is not going to work at all.
More Dmesg output and Xorg logs ASAP.

On Mon, Jul 20, 2015 at 4:30 AM, Richard Jasmin frazzledj...@gmail.com
wrote:

 Package: linux-image-4.0.0-2-amd64
 Version: 4.0.8-1
 Severity: Major

 ATI opensource drivers are broken once more and cause X11 to fail to
 start when stretch is installed. Hardware used is a A8-4500M QUAD core
 AMD Radeon APU. This doesnt happen in Jessie. Flgrx is not installed
 during this time. Installing said package may fix the issue but was
 untested because wifi was not configured. Suggest porting Fedora 22's
 latest ATI drivers. They are open source and work without issue.They
 have a version list available online so you can see what version of
 packages you are using to compare it to fedora's.


 --
 To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/1437359444.30318.11.ca...@gmail.com




-- 
Ciao e buona giornata.

GP! In mezzo al campo stai proprio schifoso!
Coach M.Russo


Bug#792913: closed by Ben Hutchings <b...@decadent.org.uk> (Re: (no subject))

2015-10-27 Thread Gianluca Renzi
I have found some issue regarding the drm driver for radeon with kernel in
sid/stretch (I am working right now and I don't recall the correct kernel
version). So I suppose there is some misunderstanding between the xorg
radeon driver and drm kernel radeon driver.
Anyway this issue is only for running xorg without any /etc/X11/xorg.conf.
If there is such file, the only issue is it NEEDS the BusID for card,
because it fails not founding any.
Otherwise it works for 2D acceleration.
In my architecture (BIG ENDIAN PowerPC G5) there is another issue after 30
minutes, it simply hangs like some DMA-CPU or whatever and IT IS NOT
RELATED TO THE BUS OR CARD ITSELF.
If I switch to use the fbdev over the radeon driver, it works fine
forever Maybe something related to MSI Interrupt in this particular
configuration???
I have to check.

For NVIDIA Driver too: I have found there are some issue on loading FCODE /
BIOS  Firmware Code for NV6600 (NV43). The Linux PPC64 Kernel has 64K
PAGESIZE and the nvidia driver needs 4K PAGESIZE
Another issue is the firmware downloading is known to be ok in linux kernel
4.3.0-rc6.

Another issue is MESA: maybe the 11.3 version of MESA fix the BIG
ENDIANNESS issue for using accelerated 3d HW on those models...
Anyone is able to confirm this?

Best regards,



On Tue, Oct 27, 2015 at 5:14 AM, Gmails  wrote:

>
> UH..are you dumb as nails?
> "Suggest porting Fedora 22's
> latest ATI drivers. They are open source and work without issue."
>
> FLGRX may indeed work, once wifi is brought online, however, wifi was not
> connectable as nonfree drivers are not by default installed.
>
> On Sat, 10 Oct 2015 21:15:08 +
> ow...@bugs.debian.org (Debian Bug Tracking System) wrote:
>
> > This is an automatic notification regarding your Bug report
> > which was filed against the src:linux package:
> >
> > #792913: Package: linux-image-4.0.0-2-amd64
> >
> > It has been closed by Ben Hutchings .
> >
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Ben Hutchings <
> b...@decadent.org.uk> by
> > replying to this email.
> >
> >
> > --
> > 792913: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792913
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
>
>


-- 
Ciao e buona giornata.

"GP! In mezzo al campo stai proprio schifoso!"
Coach M.Russo


Bug#800085: linux-image-4.1.0-2-armmp: The ethernet fails to come up on my Allwinner A10 device.

2015-09-26 Thread Gianluca Renzi
Sorry but I don't agree with you. Supposing the allwinner A10 device need some 
voltage regulator drivers to be enabled in the kernel to have some devices in a 
working state, this not hurts some other devices that have some other 
configuration setting different in hardware layout. They are defined in the 
device tree for this particular machine, vendor or somewhere else. So the 
drivers for the regulator can be safely inserted into the A10 Debian kernel and 
you will don't break down anything.

Ben Hutchings  ha scritto:

>Control: tag -1 - newcomer
>Control: tag -1 moreinfo
>
>On Sat, 2015-09-26 at 12:10 -0400, Matthew Schneider wrote:
>> Package: src:linux
>> Version: 4.1.6-1
>> Severity: important
>> Tags: newcomer
>> 
>> Dear Maintainer,
>> 
>>* What led up to the situation?
>> Attempted to install the mainline Debian kernel for the first time on
>> this system.
>>* What was the outcome of this action?
>> The ethernet did not come up. 
>> 
>> The problem seems to be outlined and solved here: 
>> http://comments.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17147
>>  
>> It would seem that an additional module needs to be included for it
>> to work correctly.
>[...]
>
>None of the extra modules that were enabled as a 'solution' have
>anything to do with this hardware (or any real hardware).  So I don't
>think we have a real solution.
>
>Please send the boot log from Linux 4.1 (or 4.2, which just landed in
>unstable).
>
>Ben.
>
>-- 
>Ben Hutchings
>Any smoothly functioning technology is indistinguishable from a rigged demo.


Bug#808043: linux-image-4.3.0-1-powerpc64: Fail to load md_mod with unknow symbol error

2016-01-03 Thread Gianluca Renzi
As for today, the binutils and the kernel (4.3.0-1ppc) upgrade did not fix
the issue.
Right now I am compiling by myself the 4.3-source package and try to see if
it shows some differences...


On Wed, Dec 16, 2015 at 10:38 AM, Christian Marillat 
wrote:

> On 15 déc. 2015 19:12, Ben Hutchings  wrote:
>
> [...]
>
> > OK, so everything is failing because the 'mcount' symbol (used for
> > function tracing) is not found.  It is supposed to be exported from
> > vmlinux.  Comparing the two versions, there's no difference (aside from
> > addresses) in the symbols related to mcount, so I think there's a
> > deeper problem in the module loader.
>
> Thanks for the precise analysis of the bug report.
>
> Christian
>
>


-- 
Ciao e buona giornata.

"GP! In mezzo al campo stai proprio schifoso!"
Coach M.Russo


Bug#808246: Maybe the bugs are related

2015-12-23 Thread Gianluca Renzi
In this case I suppose even the userspace code (dynamic linking library)
could not to be used
with this linker bug and not only the kernel module loader tool. The
undefined symbols are discarded in every way. The only way to ensure a
correct code buildup is to use a -static linking of any external library in
every piece of code. So no dynamic linking is usable in that way. This bug
seems so unreal to me...
Are the gcc team people so silly not to try any created code (even a simple
checking for an external library) in every supported platform for binutils
and gcc???
I suppose not. Are you sure of the bug?
Can you ask the gnu gcc people to test the ld in a kvm with ppc64 machine?

On Tue, Dec 22, 2015 at 11:45 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> I found indications that perhaps both problems are in fact caused by ld
> no longer including undefined symbols in the output.
>
> Here is a section from the working module built with old binutils:
>
>   0012980: 0047 4343 3a20 2844 6562 6961 6e20 342e  .GCC: (Debian 4.
>   0012990: 392e 322d 3130 2920 342e 392e 3200 0047  9.2-10) 4.9.2..G
>   00129a0: 4343 3a20 2844 6562 6961 6e20 342e 392e  CC: (Debian 4.9.
>   00129b0: 322d 3130 2920 342e 392e 3200 0047 4343  2-10) 4.9.2..GCC
>   00129c0: 3a20 2844 6562 6961 6e20 342e 392e 322d  : (Debian 4.9.2-
>   00129d0: 3130 2920 342e 392e 3200 0047 4343 3a20  10) 4.9.2..GCC:
>   00129e0: 2844 6562 6961 6e20 342e 392e 322d 3130  (Debian 4.9.2-10
>   00129f0: 2920 342e 392e 3200 0047 4343 3a20 2844  ) 4.9.2..GCC: (D
>   0012a00: 6562 6961 6e20 342e 392e 322d 3130 2920  ebian 4.9.2-10)
>   0012a10: 342e 392e 3200 0047 4343 3a20 2844 6562  4.9.2..GCC: (Deb
>   0012a20: 6961 6e20 342e 392e 322d 3130 2920 342e  ian 4.9.2-10) 4.
>   0012a30: 392e 3200 0047 4343 3a20 2844 6562 6961  9.2..GCC: (Debia
>   0012a40: 6e20 342e 392e 322d 3130 2920 342e 392e  n 4.9.2-10) 4.9.
>   0012a50: 3200 0047 4343 3a20 2844 6562 6961 6e20  2..GCC: (Debian
>   0012a60: 342e 392e 322d 3130 2920 342e 392e 3200  4.9.2-10) 4.9.2.
>   0012a70: 002e 7379 6d74 6162 002e 7374 7274 6162  ..symtab..strtab
>   0012a80: 002e 7368 7374 7274 6162 002e 6e6f 7465  ..shstrtab..note
>   0012a90: 2e67 6e75 2e62 7569 6c64 2d69 6400 2e72  .gnu.build-id..r
>   0012aa0: 656c 612e 7465 7874 002e 7265 6c61 2e69  ela.text..rela.i
>   0012ab0: 6e69 742e 7465 7874 002e 7265 6c61 2e66  nit.text..rela.f
>   0012ac0: 6978 7570 002e 7265 6c61 2e65 7869 742e  ixup..rela.exit.
>   0012ad0: 7465 7874 002e 7265 6c61 2e74 6578 742e  text..rela.text.
>   0012ae0: 756e 6c69 6b65 6c79 002e 7265 6c61 5f5f  unlikely..rela__
>   0012af0: 6b73 796d 7461 625f 6770 6c00 2e72 656c  ksymtab_gpl..rel
>   0012b00: 612e 726f 6461 7461 002e 7265 6c61 5f5f  a.rodata..rela__
>   0012b10: 6275 675f 7461 626c 6500 2e72 6f64 6174  bug_table..rodat
>   0012b20: 612e 7374 7231 2e38 002e 7265 6c61 5f5f  a.str1.8..rela__
>   0012b30: 6d63 6f75 6e74 5f6c 6f63 002e 7265 6c61  mcount_loc..rela
>   0012b40: 5f5f 6578 5f74 6162 6c65 005f 5f6b 7379  __ex_table.__ksy
>   0012b50: 6d74 6162 5f73 7472 696e 6773 002e 6d6f  mtab_strings..mo
>   0012b60: 6469 6e66 6f00 5f5f 7665 7273 696f 6e73  dinfo.__versions
>   0012b70: 002e 7265 6c61 5f5f 6b63 7263 7461 625f  ..rela__kcrctab_
>   0012b80: 6770 6c00 2e72 656c 612e 6461 7461 002e  gpl..rela.data..
>   0012b90: 7265 6c61 2e64 6174 612e 7265 6c2e 726f  rela.data.rel.ro
>   0012ba0: 002e 7265 6c61 2e6f 7064 002e 7265 6c61  ..rela.opd..rela
>   0012bb0: 2e74 6f63 002e 7265 6c61 2e67 6e75 2e6c  .toc..rela.gnu.l
>   0012bc0: 696e 6b6f 6e63 652e 7468 6973 5f6d 6f64  inkonce.this_mod
>   0012bd0: 756c 6500 2e62 7373 002e 7374 7562 7300  ule..bss..stubs.
>   0012be0: 2e66 7472 6163 652e 7472 616d 7000 2e63  .ftrace.tramp..c
>   0012bf0: 6f6d 6d65 6e74       omment..
>
> And the same section from the new binutils build (the disassenmbled
> module is totally identical as far as code is concerned):
>
>   0012980: 0047 4343 3a20 2844 6562 6961 6e20 342e  .GCC: (Debian 4.
>   0012990: 392e 322d 3130 2920 342e 392e 3200 0047  9.2-10) 4.9.2..G
>   00129a0: 4343 3a20 2844 6562 6961 6e20 342e 392e  CC: (Debian 4.9.
>   00129b0: 322d 3130 2920 342e 392e 3200 0047 4343  2-10) 4.9.2..GCC
>   00129c0: 3a20 2844 6562 6961 6e20 342e 392e 322d  : (Debian 4.9.2-
>   00129d0: 3130 2920 342e 392e 3200 0047 4343 3a20  10) 4.9.2..GCC:
>   00129e0: 2844 6562 6961 6e20 342e 392e 322d 3130  (Debian 4.9.2-10
>   00129f0: 2920 342e 392e 3200 0047 4343 3a20 2844  ) 4.9.2..GCC: (D
>   0012a00: 6562 6961 6e20 342e 392e 322d 3130 2920  ebian 4.9.2-10)
>   0012a10: 342e 392e 3200 0047 4343 3a20 2844 6562  4.9.2..GCC: (Deb
>   0012a20: 6961 6e20 342e 392e 322d 3130 2920 342e  ian 4.9.2-10) 4.
>   0012a30: 392e 3200 0047 4343 3a20 2844 6562 6961  9.2..GCC: (Debia
>   0012a40: 6e20 342e 392e 322d 3130 2920 342e 392e  n 4.9.2-10) 4.9.
>   0012a50: 3200 0047 4343 3a20 2844 6562 6961 6e20  2..GCC: (Debian
>   0012a60: 342e 392e 322d 3130 2920 342e 392e 3200  

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

2016-10-06 Thread Gianluca Renzi
Just a clue: try to add a module parameter, for example videodepth= where
you pass to the module offb.
So if not passed gets the default, otherwise get the correct bpp value
(8,15,16,24,32)???


On Thu, Oct 6, 2016 at 4:13 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Thu, Oct 06, 2016 at 07:44:35AM +0200, Mathieu Malaterre wrote:
> > That's precisely what I tried yesterday.
> >
> > Anytime I press 'Enter' after '22 set-mode' or '32 set-depth' I loose
> > display (either black or corrupted). when I then type 'boot' it goes
> > back to normal 8 bits. I have access to another Mac Mini G4 and even a
> > Gigabit Ethernet to test.
>
> Hmm, oh well.  No idea how to test it then, other than hard coding 32bpp
> in the offb.c overriding what it gets from the firmware.
>
> Still fixing the reversed red/blue would be nice.
>
> Does the radeonfb have the red/blue reversal problem in pseudocolor mode
> (I think that's what it came up in too by default)?
>
> --
> Len Sorensen
>
>


-- 
Ciao e buona giornata.

"GP! In mezzo al campo stai proprio schifoso!"
Coach M.Russo


Bug#845382: BUG: soft lockup when radeon modesetting

2016-11-22 Thread Gianluca Renzi
I am facing the same nmi bug soft lock in Apple g5 quad core with radeon
ati hd7460 pci-express (the bug came in hypervisor console driver hvcs.ko)

Il 22/nov/2016 11:27 PM, "Václav Ovsík"  ha scritto:

> Package: src:linux
> Version: 4.8.7-1
> Severity: normal
>
> Dear Maintainer,
> I'm unable to boot into functional system with KMS radeon. When
> radeon.modeset=0 on kernel command-line system it starts and run OK.
> Without disabled modeset, mostly the screen goes blank, but sometimes
> the messages stays on console. System is locked and not respond to sysrq
> or so. Kernel stack is displayed periodically as watchdog initiates.
> Captured messages (using netconsole) are attached.
>
> Regards
> --
> Zito
>
> -- Package-specific info:
> ** Version:
> Linux version 4.8.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version
> 5.4.1 20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.7-1 (2016-11-13)
>
> ** Command line:
> BOOT_IMAGE=/vmlinuz-4.8.0-1-amd64 
> root=UUID=632652f0-7f3c-4316-a74d-d05f2fd4b3ae
> ro radeon.modeset=0
>
> ** Not tainted
>
> ** Kernel log:
> [3.010746] scsi 6:0:0:1: Direct-Access Generic  STORAGE DEVICE
>  9317 PQ: 0 ANSI: 0
> [3.011944] scsi 6:0:0:2: Direct-Access Generic  STORAGE DEVICE
>  9317 PQ: 0 ANSI: 0
> [3.013151] scsi 6:0:0:3: Direct-Access Generic  STORAGE DEVICE
>  9317 PQ: 0 ANSI: 0
> [3.082153] sd 6:0:0:3: [sde] Attached SCSI removable disk
> [3.083229] sd 6:0:0:0: [sdb] Attached SCSI removable disk
> [3.084577] sd 6:0:0:1: [sdc] Attached SCSI removable disk
> [3.085913] sd 6:0:0:2: [sdd] Attached SCSI removable disk
> [4.576131] floppy0: no floppy controllers found
> [4.637754] PM: Starting manual resume from disk
> [4.637800] PM: Hibernation image partition 8:2 present
> [4.637801] PM: Looking for hibernation image.
> [4.639867] PM: Image not found (code -22)
> [4.639868] PM: Hibernation image not present or could not be loaded.
> [5.144483] EXT4-fs (sda3): mounted filesystem with ordered data mode.
> Opts: (null)
> [6.504046] random: crng init done
> [6.629488] ip_tables: (C) 2000-2006 Netfilter Core Team
> [6.773851] systemd[1]: systemd 232 running in system mode. (+PAM
> +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
> [6.774077] systemd[1]: Detected architecture x86-64.
> [6.870642] systemd[1]: Set hostname to .
> [8.285798] systemd[1]: Listening on LVM2 metadata daemon socket.
> [8.286228] systemd[1]: Listening on LVM2 poll daemon socket.
> [8.286680] systemd[1]: Set up automount Arbitrary Executable File
> Formats File System Automount Point.
> [8.286996] systemd[1]: Listening on Device-mapper event daemon FIFOs.
> [8.287353] systemd[1]: Listening on Journal Audit Socket.
> [8.287674] systemd[1]: Started Dispatch Password Requests to Console
> Directory Watch.
> [8.287972] systemd[1]: Listening on RPCbind Server Activation Socket.
> [9.059352] loop: module loaded
> [9.149613] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro
> [9.498760] RPC: Registered named UNIX socket transport module.
> [9.498803] RPC: Registered udp transport module.
> [9.498837] RPC: Registered tcp transport module.
> [9.498871] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [   10.258718] systemd-journald[221]: File /var/log/journal/
> 0ca8a8b0a1569675c187692c5066cae3/system.journal corrupted or uncleanly
> shut down, renaming and replacing.
> [   10.623394] systemd-journald[221]: Received request to flush runtime
> journal from PID 1
> [   11.485959] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:
> 00/PNP0C0C:00/input/input6
> [   11.486007] ACPI: Power Button [PWRB]
> [   11.486125] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:
> 00/input/input7
> [   11.486164] ACPI: Power Button [PWRF]
> [   11.552262] piix4_smbus :00:14.0: SMBus Host Controller at 0xb00,
> revision 0
> [   11.552358] piix4_smbus :00:14.0: Auxiliary SMBus Host Controller
> at 0xb10
> [   11.724952] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
> [   11.739879] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
> [   11.740025] sp5100_tco: PCI Vendor ID: 0x1002, Device ID: 0x4385,
> Revision ID: 0x14
> [   11.740083] sp5100_tco: failed to find MMIO address, giving up.
> [   11.868374] [drm] Initialized drm 1.1.0 20060810
> [   11.877794] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [   11.877895] sr 4:0:1:0: Attached scsi generic sg1 type 5
> [   11.877981] sd 6:0:0:0: Attached scsi generic sg2 type 0
> [   11.878062] sd 6:0:0:1: Attached scsi generic sg3 type 0
> [   11.878149] sd 6:0:0:2: Attached scsi generic sg4 type 0
> [   11.878229] sd 6:0:0:3: Attached scsi generic sg5 type 0
> [   11.990613] parport_pc 00:04: reported by Plug and Play ACPI
> [   11.990714] parport0: PC-style at 0x378, irq 7 

Bug#826796: Request for a new: linux-image-powerpc64-4K

2020-04-23 Thread Gianluca Renzi
On Thu, Apr 23, 2020 at 4:33 AM Ben Hutchings  wrote:

> On Tue, 2020-04-21 at 11:26 +0200, Mathieu Malaterre wrote:
> > Dear Debian-kernel team,
> >
> > > Would it be possible to ship an alternate ppc64 kernel build without
> > > the 64K page option ?
> >
> > Could someone please clarify if this is possible/acceptable ? The new
> > ppc64 kernel would not be the default but could be installed on G5
> > machine after installation.
>
> I'm sorry this is still unresolved.  I have a couple of questions:
>
> * How will people discover this and know that they should use it?  If
> the installer is still being updated for ppc64, shouldn't we select
> this kernel automatically when an Nvidia PCI device is detected?
>
>
It could be an option during installation. It does not hurt anyone with
bigendian and nvidia cards.
Other PPC should be little endian and the installer should be act
differently in this case.



> * Has anyone talked to the nouveau developers recently about either (a)
> fixing support for larger pages or (b) fixing the dependencies for the
> driver so it can't be built in an unsupported configuration?
>
> In any case, if nouveau is completely broken with 64K pages then we
> should make sure nouveau is disabled in our default ppc64
> configuration.
>
>
You are right. I suppose there is some misunderstood or a techincal issue
to have nvidia drivers using 4K page size.
This problem is well known since 2015 at least. Every people involved in
the PPC side are knowing this from a long time, so I wondering if anybody
from NVIDIA developing side are questioning about this issue.
Or simply it is too hard or limiting decrease this to 4K page. Just my 2
cents.
Regards,
Gianluca Renzi
-- 
Ciao e buona giornata.

"GP! In mezzo al campo stai proprio schifoso!"
Coach M.Russo


Re: What to do with d-i on armel?

2024-03-03 Thread Gianluca Renzi
The same here. We never used the d-i but we are using Debian systems
(kernel and root file system) as daily bases of our line of products
embedded systems. Hundred of thousands of boards are using Debian since
Debian Lenny 5.0. From armel to armhf 32 bit systems.
So a drop of the armel and/or armhf will force us to a very complicated
rearrangement of our build systems.
Please don't do that if you can.

Best regards


Il lun 4 mar 2024, 01:34 Martin  ha scritto:

> On 2024-01-09 22:19, Martin wrote:
> > On 2024-01-09 19:56, Emanuele Rocca wrote:
> >> though. Any armel users out there? :-)
> >
> > My employer uses Debian on armel, but not d-i :-)
>
> I should add: We never used d-i on armel and have our own kernel.
> Most other stuff is plain Debian, though.
>
>


Bug#808043: linux-image-4.3.0-1-powerpc64: Fail to load md_mod with unknow symbol error

2016-01-03 Thread Gianluca GP Renzi
Nope. It does not work. Compiling 4.3.3 using  the latest binutils leads to the 
same problem. Why?

Christian Marillat  ha scritto:

>On 15 déc. 2015 19:12, Ben Hutchings  wrote:
>
>[...]
>
>> OK, so everything is failing because the 'mcount' symbol (used for
>> function tracing) is not found.  It is supposed to be exported from
>> vmlinux.  Comparing the two versions, there's no difference (aside from
>> addresses) in the symbols related to mcount, so I think there's a
>> deeper problem in the module loader.
>
>Thanks for the precise analysis of the bug report.
>
>Christian
>