Bug#696059: linux: PATCH required for server interrupt load balancing/irqbalance (tested)
Dear maintainer, I must agree with Henrique de Moraes Holschuh and Sebastian Kutsch. I've tried the patch from Henrique for two months in a 3.2.35 kernel and it runs smooth without any problems. I use irqbalance (1.0.3-3) with --powertresh option. Please insert this patch into the next wheezy-kernel. Kind regards Holger Lüdecke smime.p7s Description: S/MIME Kryptografische Unterschrift
Bug#704242: Driver for PL-2303 HX not working
Am 18.04.2013 11:35, schrieb Johan Hovold: I have used a little perl program that opens the port and send Test to the looped back device. The length of the log looks good. Great. Now I can see what's going on. The only problem (?) is that everything seems to be working. The write succeeds and the four bytes are read back as they should by the driver. But where the data has gone? With cutecom i can see that some of the first bytes are looped back. It must be possible to read any binary (streamed) data. The first thing that comes to mind that could prevent you from reading the received data would be if the tty device is configured for canonical input processing. Have you made sure this is not the case? Can you read the data back if you add a newline to your test string (e.g. test\n)? Hmmn - i don't know which method is used by programs like cutecom or putty? But i know everything works fine before. In this programs every data is terminated with newline, but it does not work. I use this script with a ch341 adapter and it works. Hmmm. Did you remember to initialise the device (e.g. set the termios flags)? Here you can see what's initialized in Perl: use Device::SerialPort 0.12; $port-baudrate(9600) || die failed setting baudrate; $port-parity(none)|| die failed setting parity; $port-databits(8) || die failed setting databits; $port-handshake(none) || die failed setting handshake; $port-write_settings|| die could not write settings; $port-lookclear || die could not empty buffer; $port-read_char_time(0);# don't wait for each character $port-read_const_time(1000);# 1 second per unfulfilled read call my $STALL_DEFAULT = 1;# how many seconds to wait for new input Cheers Karsten Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5170f15f.50...@dct.mine.nu
Bug#705586: linux-image-3.2.0-4-amd64: ath9k_htc fails to initialize with tl-wn722n; regression vs sqeeze backport
It does look like this is less an issue of regression, but rather an issue of the hardware combination used. I got another machine running Weezie and the wireless adapter seems to work just fine at first glance(not throwing an error immediately after loading firmware). If you (maintainer) want me to produce some debug logs, then go ahead and tell me how. Otherwise I don't know where to go from here. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366356498.2514.12.camel@destruction.l
Bug#704242: Driver for PL-2303 HX not working
Am 18.04.2013 12:56, schrieb Johan Hovold: Can you generate a log where bytes are actually lost? Nothing seemed to get lost in the previous log you posted. This was a log with lost data. The logs seems to make politics. ;-) How can i enable the debugging in kernel 3.8.5? Make sure debugfs is mounted: mount -t debugfs none /sys/kernel/debug and then enable debugging: echo module usbserial +p/sys/kernel/debug/dynamic_debug/control echo module pl2303 +p/sys/kernel/debug/dynamic_debug/control Johan Sorry - this does not work for me? root@PC# mount -t debugfs none /sys/kernel/debug root@PC# mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1014924,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819796k,mode=755) /dev/disk/by-uuid/5166cbb1-8234-4127-bb0b-bbfda1658b68 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1679740k) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) none on /sys/kernel/debug type debugfs (rw,relatime) root@PC# echo module usbserial +p /sys/kernel/debug/dynamic_debug/control bash: /sys/kernel/debug/dynamic_debug/control: Datei oder Verzeichnis nicht gefunden root@PC# ls -l /sys/kernel/debug insgesamt 0 drwx-- 14 root root 0 Apr 19 10:27 . drwxr-xr-x 6 root root 0 Apr 19 10:27 .. drwxr-xr-x 2 root root 0 Apr 19 10:27 acpi drwxr-xr-x 17 root root 0 Apr 19 10:27 bdi drwxr-xr-x 2 root root 0 Apr 19 10:27 extfrag -r--r--r-- 1 root root 0 Apr 19 10:27 gpio drwxr-xr-x 4 root root 0 Apr 19 10:27 hid drwxr-xr-x 2 root root 0 Apr 19 10:27 kprobes drwxr-xr-x 2 root root 0 Apr 19 10:27 kvm drwxr-xr-x 2 root root 0 Apr 19 10:27 mce drwxr-xr-x 2 root root 0 Apr 19 10:27 regmap drwxr-xr-x 3 root root 0 Apr 19 10:27 regulator -rw-r--r-- 1 root root 0 Apr 19 10:27 sched_features -r--r--r-- 1 root root 0 Apr 19 10:27 suspend_stats drwxr-xr-x 5 root root 0 Apr 19 10:27 tracing drwxr-xr-x 2 root root 0 Apr 19 10:27 usb -r--r--r-- 1 root root 0 Apr 19 10:27 wakeup_sources drwxr-xr-x 2 root root 0 Apr 19 10:27 x86 Karsten -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51710229.1000...@dct.mine.nu
Bug#704242: Driver for PL-2303 HX not working
On Fri, Apr 19, 2013 at 09:25:19AM +0200, Karsten Malcher wrote: Am 18.04.2013 11:35, schrieb Johan Hovold: I have used a little perl program that opens the port and send Test to the looped back device. The length of the log looks good. Great. Now I can see what's going on. The only problem (?) is that everything seems to be working. The write succeeds and the four bytes are read back as they should by the driver. But where the data has gone? With cutecom i can see that some of the first bytes are looped back. It must be possible to read any binary (streamed) data. Yes, but not in canonical mode as then the input is buffered by the kernel tty-layer until certain characters are encountered. The first thing that comes to mind that could prevent you from reading the received data would be if the tty device is configured for canonical input processing. Have you made sure this is not the case? Can you read the data back if you add a newline to your test string (e.g. test\n)? Hmmn - i don't know which method is used by programs like cutecom or putty? Unless it's configurable it should be non-canonical mode. But i know everything works fine before. In this programs every data is terminated with newline, but it does not work. You mean that you updated your test program so that it writes test\n but it still does not work? I use this script with a ch341 adapter and it works. Hmmm. Did you remember to initialise the device (e.g. set the termios flags)? Here you can see what's initialized in Perl: use Device::SerialPort 0.12; $port-baudrate(9600) || die failed setting baudrate; $port-parity(none)|| die failed setting parity; $port-databits(8) || die failed setting databits; $port-handshake(none) || die failed setting handshake; $port-write_settings|| die could not write settings; $port-lookclear || die could not empty buffer; $port-read_char_time(0);# don't wait for each character $port-read_const_time(1000);# 1 second per unfulfilled read call my $STALL_DEFAULT = 1;# how many seconds to wait for new input I don't use perl so can't help you there. Search for perl and icanon or something. You can use stty to determine if canonical-mode is enabled; the output of 'stty -aF /dev/ttyUSB0' contains icanon if enabled and -icanon otherwise. By default it is enabled. You should also make sure that VMIN and VTIME are initialised in non-canonical mode. Specifically, if VMIN is greater than the number of characters written by your test program over the loopback and VTIME is 0, read will block also in non-canonical mode. Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419084928.GA32104@localhost
Bug#704242: Driver for PL-2303 HX not working
On Fri, Apr 19, 2013 at 10:36:57AM +0200, Karsten Malcher wrote: Am 18.04.2013 12:56, schrieb Johan Hovold: Can you generate a log where bytes are actually lost? Nothing seemed to get lost in the previous log you posted. This was a log with lost data. The logs seems to make politics. ;-) Then the problem is most likely not in the driver as the characters are being read back in the log you provided. Now that you have compiled your own kernel, you could run a git bisect to learn if anything else has changed in the kernel (possibly interacting with your test setup) which can explain why things stopped working. I would suggest that you convince yourself that your minimal test setup is correct first, though. Perhaps using the same minimal program (init, write, read) on a working pl2303 device if you have one. How can i enable the debugging in kernel 3.8.5? Make sure debugfs is mounted: mount -t debugfs none /sys/kernel/debug and then enable debugging: echo module usbserial +p/sys/kernel/debug/dynamic_debug/control echo module pl2303 +p/sys/kernel/debug/dynamic_debug/control Johan Sorry - this does not work for me? root@PC# mount -t debugfs none /sys/kernel/debug root@PC# mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1014924,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819796k,mode=755) /dev/disk/by-uuid/5166cbb1-8234-4127-bb0b-bbfda1658b68 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1679740k) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) none on /sys/kernel/debug type debugfs (rw,relatime) root@PC# echo module usbserial +p /sys/kernel/debug/dynamic_debug/control bash: /sys/kernel/debug/dynamic_debug/control: Datei oder Verzeichnis nicht gefunden Your kernel is not configured to use dynamic debugging. You need to enable CONFIG_DYNAMIC_DEBUG=y. Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419090445.GB32104@localhost
Bug#705168: Wheezy fails to boot linux/3.2.41-2 kernel
I'm also affected by this bug. lspci | grep VGA 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200] 02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 LE [Radeon HD 3450] Removing the discrete video card makes the KMS work again. -- Rafał Rutkowski -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAHkK7nP-o8kVH-uYbgSbU+j5a7B4=9Ui7fpsdZJOGu4V=xw...@mail.gmail.com
Bug#705711: linux-image-2.6.32-5-686: AMD A6-3500 APU with Radeon HD 6530D not supported
Hello Ben. JFYI with apt-get install -t squeeze-backports linux-image-686 firmware-linux xorg libdrm2 libdrm-radeon1 libgl1-mesa-glx it worked although with the FBDEV driver; the Radeon driver loads first but doesn't say anything about not supporting it, it just unloads and then VESA refuses to load because it detects KMS, so then is the FBDEV turn that uses the FBDev API exposed by the KMS driver and it works. Is good enough for office work so I am ok. Maybe this info could help someone else with the same problem on Squeeze. If you know or have some tip to try to load the Radeon driver let me know, but it isn't too important for me at least. Thanks a lot! El 18/04/13 20:12, Ben Hutchings escribió: Control: tag -1 wontfix On Thu, Apr 18, 2013 at 07:09:03PM -0300, Ivan Baldo wrote: Package: linux-2.6 Version: 2.6.32-46 Severity: wishlist Tags: squeeze This is just to let you know. I don't know if a backport to support that driver is worthwhile or not, complex or trivial, etc... The VESA driver is unstable, sometimes X starts, sometimes not, when it starts it doesn't support the monitors native resolution. Thanks for your consideration! Happy hacking! Sorry, it won't be possible to add any new graphics hardware support to 'squeeze'. The kernel and X packages in squeeze-backports might support this hardware properly; otherwise try Debian 7.0 'wheezy' which will be released very shortly. Ben. -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: iba...@codigolibre.net - http://go.to/ibaldo -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51713012.5020...@adinet.com.uy
Bug#704242: Driver for PL-2303 HX not working
Hi Johan, Am 19.04.2013 11:04, schrieb Johan Hovold: This was a log with lost data. The logs seems to make politics. ;-) Then the problem is most likely not in the driver as the characters are being read back in the log you provided. Stop - it's really possible that i send not enough bytes. Sometimes up to 6 Bytes will come back. This time i send this string (3.2.0): 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n I get back the first 3 Bytes of it. Log is attached. Before closing the connection Perl sends a 'stty -aF /dev/ttyUSB0' and prints the result: speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 16; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke canonical-mode is not enabled and I get back 3 bytes - so data is not lost complete. With cutecom it's -icanon also. So everything should be fine. There are 2 beasty questions left: 1. Why it works with PL2303H ? 2. Why i receive sometimes the first bytes? Now that you have compiled your own kernel, you could run a git bisect to learn if anything else has changed in the kernel (possibly interacting with your test setup) which can explain why things stopped working. I learned much in kernel testing the last time ... :-) Maybe there is a HowTo for the bisect testing? Your kernel is not configured to use dynamic debugging. You need to enable CONFIG_DYNAMIC_DEBUG=y. Oh - then i must compile again. I found # CONFIG_DYNAMIC_DEBUG is not set in .config. Johan Karsten [ 1443.104346] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_install [ 1443.104363] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_open - port 0 [ 1443.104366] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - port 0 [ 1443.104581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x8:0x0 0 [ 1443.106606] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x9:0x0 0 [ 1443.106619] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - port 0 [ 1443.108584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 1443.108594] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - data bits = 8 [ 1443.108603] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud requested = 9600 [ 1443.108611] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud set = 9600 [ 1443.108618] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - stop bits = 1 [ 1443.108625] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - parity = none [ 1443.110595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x21:0x20:0:0 7 [ 1443.112584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0 7 - 80 25 0 0 0 0 8 [ 1443.114595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x0 0 [ 1443.114605] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting read urb [ 1443.114627] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting interrupt urb [ 1443.116581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: set_control_lines - value = 3, retval = 0 [ 1443.116821] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 [ 1443.116832] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401 [ 1443.116841] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401 [ 1443.116903] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 [ 1443.116913] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
Bug#704242: Driver for PL-2303 HX not working
On Fri, Apr 19, 2013 at 02:26:48PM +0200, Karsten Malcher wrote: Hi Johan, Am 19.04.2013 11:04, schrieb Johan Hovold: This was a log with lost data. The logs seems to make politics. ;-) Then the problem is most likely not in the driver as the characters are being read back in the log you provided. Stop - it's really possible that i send not enough bytes. Sometimes up to 6 Bytes will come back. This time i send this string (3.2.0): 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n I get back the first 3 Bytes of it. Log is attached. Was it really the same log? In the log below there is an error reported but it looks like no data at all is returned: [ 1443.120415] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c: usb_serial_generic_write - port 0 [ 1443.120430] pl2303 ttyUSB0: usb_serial_generic_write_start - length = 101, data = 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 0a [ 1443.122568] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback - nonzero read bulk status received: -84 Either way, the error is EILSEQ (-84) which usually indicates hardware problems. [...] There are 2 beasty questions left: 1. Why it works with PL2303H ? Different device, different hardware. 2. Why i receive sometimes the first bytes? Your particular device could be flakey and sometimes you're able to read a few bytes. Now that you have compiled your own kernel, you could run a git bisect to learn if anything else has changed in the kernel (possibly interacting with your test setup) which can explain why things stopped working. I learned much in kernel testing the last time ... :-) Maybe there is a HowTo for the bisect testing? I don't have any good pointers at hand except for the git documentation of git-bisect. But perhaps you don't need to do a bisect. If the hardware is broken then knowing which performance increase in the kernel pushed it over the edge isn't really gonna be of much use as the driver is still working with other HX-devices (I have one here). If you still want to pursue this, you should try to reproduce the error on a v3.8 kernel (look in the logs for errors from usb_serial_generic_read_bulk_callback). Then you could try to reduce the bulk-in and out buffer sizes in the driver (simply comment out those fields in the pl2303_device struct) and perhaps also to reduce the number of read and write urbs (I can tell you how later). Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419143923.GC32104@localhost
[PATCH] Correctly handle $KCONFIG_CONFIG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I noticed that the builddeb packaging script used by make deb-pkg didn't
handle $KCONFIG_CONFIG environment for setting the config file.
This patch adds support for the variable.
Signed-off-by: Yves-Alexis Perez cor...@debian.org
- ---
scripts/package/builddeb | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 3c6c0b1..243d3c9 100644
- --- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -41,9 +41,9 @@ create_package() {
parisc*)
debarch=hppa ;;
mips*)
- - debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y .config echo el) ;;
+ debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y $KCONFIG_CONFIG
echo el) ;;
arm*)
- - debarch=arm$(grep -q CONFIG_AEABI=y .config echo el) ;;
+ debarch=arm$(grep -q CONFIG_AEABI=y $KCONFIG_CONFIG echo el)
;;
*)
echo 2
echo ** ** ** WARNING ** ** ** 2
@@ -105,12 +105,12 @@ fi
if [ $ARCH = um ] ; then
$MAKE linux
cp System.map $tmpdir/usr/lib/uml/modules/$version/System.map
- - cp .config $tmpdir/usr/share/doc/$packagename/config
+ cp $KCONFIG_CONFIG $tmpdir/usr/share/doc/$packagename/config
gzip $tmpdir/usr/share/doc/$packagename/config
cp $KBUILD_IMAGE $tmpdir/usr/bin/linux-$version
else
cp System.map $tmpdir/boot/System.map-$version
- - cp .config $tmpdir/boot/config-$version
+ cp $KCONFIG_CONFIG $tmpdir/boot/config-$version
# Not all arches include the boot path in KBUILD_IMAGE
if [ -e $KBUILD_IMAGE ]; then
cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version
@@ -119,7 +119,7 @@ else
fi
fi
- -if grep -q '^CONFIG_MODULES=y' .config ; then
+if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
INSTALL_MOD_PATH=$tmpdir make KBUILD_SRC= modules_install
if [ $ARCH = um ] ; then
mv $tmpdir/lib/modules/$version/*
$tmpdir/usr/lib/uml/modules/$version/
@@ -240,7 +240,7 @@ fi
# Build header package
(cd $srctree; find . -name Makefile -o -name Kconfig\* -o -name \*.pl
$objtree/debian/hdrsrcfiles)
(cd $srctree; find arch/$SRCARCH/include include scripts -type f
$objtree/debian/hdrsrcfiles)
- -(cd $objtree; find .config Module.symvers include scripts -type f
$objtree/debian/hdrobjfiles)
+(cd $objtree; find $KCONFIG_CONFIG Module.symvers include scripts -type f
$objtree/debian/hdrobjfiles)
destdir=$kernel_headers_dir/usr/src/linux-headers-$version
mkdir -p $destdir
(cd $srctree; tar -c -f - -T $objtree/debian/hdrsrcfiles) | (cd $destdir;
tar -xf -)
- --
1.7.10.4
- --
Yves-Alexis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAEBCgAGBQJRca8FAAoJEG3bU/KmdcCl9HEH/AnfDEUw58DkxlNLARM8nkfO
x7DRZmSL9eLeRbalhU1iMNxSKj7An62Z7mkGGDUBVppBu6EA1G+QIFn+n/KpJIg5
ufEODYphwY1dgy0fN/i336Hu3pb60KrhuPLBFIyoe8EQQWLyG9PvM5KvjNc7937A
NZ4fhuxTdF7tm3TY0RkeaIglHCiwyYOpULtk67pRHhmedC5l1WuBspelPUj8GeH6
/8vciNnn+3cnhCPIo1YC+2784B9YWQoFEVciAkxCutzfS+UUplXya2E7J4OqDm4T
wDqfGOtAH1WlXF0AhDuhv5Fnkc+ts4fuq7KmwqOJ+MVV1n+RUOcFj0ChwDm22lY=
=wF+s
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130419205433.ga3...@scapa.corsac.net
Bug#705780: fb-modules-3.2.0-4-486-di: please include lxfb module for OLPC XO-1 support in d-i
Package: fb-modules-3.2.0-4-486-di Version: 3.2.41-2 The Geode LXFB driver used to be built into the Debian kernel. With bug #686528, it was made modular, which makes things more difficult for the XO-1 platform. OLPC XO-1 doesn't support VESA, which means the lxfb driver is required in order to get display output. Including lxfb.ko in the fb-modules udeb is necessary to add OLPC XO-1 support to d-i. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419143805.3923b...@dev.queued.net
Auto-loading lxfb on OLPC XO systems
The x86-based OLPC XO systems apparently don't support a VGA-compatible text mode, so text consoles on these systems require the lxfb driver. This was previously built-in to the i386 kernel images, but for reasons explained in in #686528 it was changed to a module. The module can be auto-loaded based on a PCI device ID. However, framebuffer drivers are generally blacklisted for auto-loading by a configuration file installed in udev, and lxfb is included in this blacklist. This will result in a regression when upgrading one of these systems from squeeze. (Although I don't think Debian kernel images have ever had complete support for them.) I've opened bug #705784 for this against udev, and Marco has said he's willing for me to NMU it. Alternately, in the kernel, I can revert the change to a module, or rename the module to evade the blacklist, but neither of those is particularly nice. But I think any kernel changes now are going to be too disruptive to the installer. Can the release team recommend what to do? Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Processed: tagging 705780
Processing commands for cont...@bugs.debian.org: tags 705780 + pending Bug #705780 [fb-modules-3.2.0-4-486-di] fb-modules-3.2.0-4-486-di: please include lxfb module for OLPC XO-1 support in d-i Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 705780: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705780 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.136643417532642.transcr...@bugs.debian.org
Bug#705788: fb-modules-3.2.0-4-486-di: please include viafb module for OLPC XO-1.5 support in d-i
Package: fb-modules-3.2.0-4-486-di Version: 3.2.41-2 The OLPC XO-1.5 doesn't support VESA. It needs the viafb driver in order to get display output. Similar to #705780, please consider including viafb.ko in the fb-modules udeb. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419220739.3883d...@dev.queued.net
