Processed: tagging as pending bugs that are closed by packages in NEW
Processing commands for [EMAIL PROTECTED]: # Sun Oct 12 07:03:19 UTC 2008 # Tagging as pending bugs that are closed by packages in NEW # http://ftp-master.debian.org/new.html # # Source package in NEW: linux-2.6 tags 499230 + pending Bug#499230: linux-image-2.6.26-1-amd64: No RTC device created, fails to get/set hardware clock There were no tags set. Tags added: pending # Source package in NEW: linux-2.6 tags 464962 + pending Bug#464962: -686 build uses long noops, that are unsupported by Transmeta Crusoe, immediate crash on boot There were no tags set. Tags added: pending # Source package in NEW: linux-2.6 tags 500279 + pending Bug#500279: linux-image-2.6.26-1-amd64: [PATCH]Kernel Oops on user keyring operations Tags were: patch Bug#499812: smbfs: Application crashed when i try to see dfs links Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 500472
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 500472 + pending Bug#500472: linux-image-2.6.26-1-openvz-amd64: NULL pointer dereference in tcp_v4_send_ack Tags were: patch fixed-upstream Bug#500963: [linux-image-2.6.26-1-openvz-686] reproducible panic while using network intensively Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501985: linux-image-2.6.26-1-openvz-686: No nfs support in openvz guest
Package: linux-image-2.6.26-1-openvz-686 Version: 2.6.26-5 Severity: important I recently tried the openvz linux kernel flavour and has some issue with mounting nfs partitions in an openvz guest. I followed the instructions at http://wiki.openvz.org/NFS openvz-host# cat /proc/sys/kernel/ve_allow_kthreads 1 openvz-host# lsmod | grep -w ^nfs nfs 214568 0 openvz-host# grep FEATURE /etc/vz/conf/200.conf FEATURES=nfs:on When I launch the openvz guest in verbose mode, I see that nfs is enabled in the feature mask: openvz-host# vzctl start 200 Starting VE ... Running: /usr/sbin/vzquota show 200 Running: /usr/sbin/vzquota on 200 -r 0 -b 1048676 -B 1153124 -i 200100 -I 220100 -e 0 -n 0 -s 0 Mounting root: /var/lib/vz/root/200 /var/lib/vz/private/200 VE is mounted Set iptables mask 0x17bf Set features mask 0002/0002 Adding IP address(es): 192.168.122.80 Running: /usr/lib/vzctl/scripts/vps-net_add /usr/share/doc/vzctl/README.Debian. Running VE script: /etc/vz/dists/scripts/debian-add_ip.sh Setting CPU units: 1000 Configure meminfo: 65536 Running VE script: /etc/vz/dists/scripts/set_dns.sh File resolv.conf was modified Running: /usr/sbin/vzquota stat 200 -f Running: vzquota setlimit 200 -b 1048576 -B 1153024 -i 20 -I 22 -e 0 -n 0 VE start in progress... however the nfs filesystem is still unknown in the openvz-guest: openvz-guest# cat /proc/filesystems ext3 nodev sysfs nodev proc nodev tmpfs nodev devpts openvz-gest# mount -t nfs nfs_server:/home /home mount: unknown filesystem type 'nfs' I had a look at the openvz patch: kernel-patches/all/2.6.26/debian/features/all/openvz/openvz.patch.bz2 and this patch doesn't seem to contain some nfs code that is found in linux-patch-openvz. For instance, the openvz patch used in linux-image-2.6.26-1-openvz-686 doesn't modify the fs/nfs/super.c file although the linux-patch-openvz does. So I wonder if nfs is enabled in openvz kernel image, and if it's not if could be enabled ? Thanks in advance for your answer. Yann -- Package-specific info: ** Version: Linux version 2.6.26-1-openvz-686 (Debian 2.6.26-5) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Wed Sep 10 19:04:44 UTC 2008 ** Command line: root=/dev/mapper/lenny--test-root ro quiet ** Not tainted ** Kernel log: [1.527527] serio: i8042 KBD port at 0x60,0x64 irq 1 [1.527527] serio: i8042 AUX port at 0x60,0x64 irq 12 [1.527527] mice: PS/2 mouse device common for all mice [1.527527] rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0 [1.527527] rtc0: alarms up to one day [1.527527] cpuidle: using governor ladder [1.527527] cpuidle: using governor menu [1.527527] No iBFT detected. [1.531202] input: AT Translated Set 2 keyboard as /class/input/input0 [1.527527] TCP cubic registered [1.527527] NET: Registered protocol family 17 [1.527527] Using IPI No-Shortcut mode [1.527527] registered taskstats version 1 [1.527527] rtc_cmos 00:01: setting system clock to 2008-10-12 11:16:51 UTC (1223810211) [1.531202] Freeing unused kernel memory: 252k freed [1.858188] ACPI: ACPI0007:00 is registered as cooling_device0 [1.858188] ACPI: ACPI0007:01 is registered as cooling_device1 [2.742819] usbcore: registered new interface driver usbfs [2.742862] usbcore: registered new interface driver hub [2.742977] usbcore: registered new device driver usb [2.745398] USB Universal Host Controller Interface driver v3.0 [2.745598] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 [2.745627] ACPI: PCI Interrupt :00:01.2[D] - Link [LNKD] - GSI 11 (level, high) - IRQ 11 [2.745683] uhci_hcd :00:01.2: UHCI Host Controller [2.745789] uhci_hcd :00:01.2: new USB bus registered, assigned bus number 1 [2.745885] uhci_hcd :00:01.2: irq 11, io base 0xc020 [2.745995] usb usb1: configuration #1 chosen from 1 choice [2.746024] hub 1-0:1.0: USB hub found [2.746032] hub 1-0:1.0: 2 ports detected [2.753079] No dock devices found. [2.774793] SCSI subsystem initialized [2.787511] libata version 3.00 loaded. [2.847196] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 [2.847201] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.847204] usb usb1: Product: UHCI Host Controller [2.847206] usb usb1: Manufacturer: Linux 2.6.26-1-openvz-686 uhci_hcd [2.847209] usb usb1: SerialNumber: :00:01.2 [2.858132] Uniform Multi-Platform E-IDE driver [2.858137] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [2.859741] PIIX3: IDE controller
Re: Please unblock linux-2.6/2.6.26-8
Otavio Salvador wrote: Bastian Blank [EMAIL PROTECTED] writes: Hi folks Please unblock linux-2.6/2.6.26-8. No objection from d-i POV. I'll wait it to be built on all architectures and do a massupload. The just missed one is mipsel, I hope it gets done by tomorrow. unblocked, I fear that it will still take a couple of hours till that one is built. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501985: linux-image-2.6.26-1-openvz-686: No nfs support in openvz guest
On Sun, Oct 12, 2008 at 03:15:10PM +0200, Yann Rouillard wrote: Package: linux-image-2.6.26-1-openvz-686 Version: 2.6.26-5 Severity: important I recently tried the openvz linux kernel flavour and has some issue with mounting nfs partitions in an openvz guest. I followed the instructions at http://wiki.openvz.org/NFS openvz-host# cat /proc/sys/kernel/ve_allow_kthreads 1 openvz-host# lsmod | grep -w ^nfs nfs 214568 0 openvz-host# grep FEATURE /etc/vz/conf/200.conf FEATURES=nfs:on When I launch the openvz guest in verbose mode, I see that nfs is enabled in the feature mask: openvz-host# vzctl start 200 Starting VE ... Running: /usr/sbin/vzquota show 200 Running: /usr/sbin/vzquota on 200 -r 0 -b 1048676 -B 1153124 -i 200100 -I 220100 -e 0 -n 0 -s 0 Mounting root: /var/lib/vz/root/200 /var/lib/vz/private/200 VE is mounted Set iptables mask 0x17bf Set features mask 0002/0002 Adding IP address(es): 192.168.122.80 Running: /usr/lib/vzctl/scripts/vps-net_add /usr/share/doc/vzctl/README.Debian. Running VE script: /etc/vz/dists/scripts/debian-add_ip.sh Setting CPU units: 1000 Configure meminfo: 65536 Running VE script: /etc/vz/dists/scripts/set_dns.sh File resolv.conf was modified Running: /usr/sbin/vzquota stat 200 -f Running: vzquota setlimit 200 -b 1048576 -B 1153024 -i 20 -I 22 -e 0 -n 0 VE start in progress... however the nfs filesystem is still unknown in the openvz-guest: openvz-guest# cat /proc/filesystems ext3 nodev sysfs nodev proc nodev tmpfs nodev devpts openvz-gest# mount -t nfs nfs_server:/home /home mount: unknown filesystem type 'nfs' I had a look at the openvz patch: kernel-patches/all/2.6.26/debian/features/all/openvz/openvz.patch.bz2 and this patch doesn't seem to contain some nfs code that is found in linux-patch-openvz. For instance, the openvz patch used in linux-image-2.6.26-1-openvz-686 doesn't modify the fs/nfs/super.c file although the linux-patch-openvz does. So I wonder if nfs is enabled in openvz kernel image, and if it's not if could be enabled ? Thanks in advance for your answer. Yann the upstream nfs fixes are abi breakers and thus can't be integrated at this point they will be for the first point release were abi breaking will be allowed again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494010: Source for dsp56k firmware
Here is the assembly-language source for the firmware, licenced under GPLv2. Adding this to the kernel source package should fix this bug. Ben. ; Author: Frederik Noring [EMAIL PROTECTED] ; ; This file is subject to the terms and conditions of the GNU General Public ; License. See the file COPYING in the main directory of this archive ; for more details. ; DSP56k loader ; Host Interface M_BCR EQU $FFFE ; Port A Bus Control Register M_PBC EQU $FFE0 ; Port B Control Register M_PBDDR EQU $FFE2 ; Port B Data Direction Register M_PBD EQU $FFE4 ; Port B Data Register M_PCC EQU $FFE1 ; Port C Control Register M_PCDDR EQU $FFE3 ; Port C Data Direction Register M_PCD EQU $FFE5 ; Port C Data Register M_HCR EQU $FFE8 ; Host Control Register M_HSR EQU $FFE9 ; Host Status Register M_HRX EQU $FFEB ; Host Receive Data Register M_HTX EQU $FFEB ; Host Transmit Data Register ; SSI, Synchronous Serial Interface M_RXEQU $FFEF ; Serial Receive Data Register M_TXEQU $FFEF ; Serial Transmit Data Register M_CRA EQU $FFEC ; SSI Control Register A M_CRB EQU $FFED ; SSI Control Register B M_SREQU $FFEE ; SSI Status Register M_TSR EQU $FFEE ; SSI Time Slot Register ; Exception Processing M_IPR EQU $ ; Interrupt Priority Register org P:$0 start jmp $40 org P:$40 ; ; Zero 16384 DSP X and Y words ; clr A #0,r0 ; clr B #0,r4 ; do #64,_block1 ; rep #256 ; moveA,X:(r0)+ B,Y:(r4)+ ;_block1; Zero (32768-512) Program words ; clr A #512,r0 ; do #126,_block2 ; rep #256 ; moveA,P:(r0)+ ;_block2 ; Copy DSP program control move#real,r0 move#upload,r1 do #upload_end-upload,_copy moveP:(r0)+,x0 movex0,P:(r1)+ _copy movep #4,X:M_HCR movep #$c00,X:M_IPR and #$fe,mr jmp upload real org P:$7ea9 upload movep #1,X:M_PBC movep #0,X:M_BCR nextjclr#0,X:M_HSR,* movep X:M_HRX,A move#3,x0 cmp x0,A #1,x0 jeq $0 _get_address jclr#0,X:M_HSR,_get_address movep X:M_HRX,r0 _get_length jclr#0,X:M_HSR,_get_length movep X:M_HRX,y0 cmp x0,A #2,x0 jeq load_X cmp x0,A jeq load_Y load_P do y0,_load jclr#0,X:M_HSR,* movep X:M_HRX,P:(r0)+ _load jmp next load_X do y0,_load jclr#0,X:M_HSR,* movep X:M_HRX,X:(r0)+ _load jmp next load_Y do y0,_load jclr#0,X:M_HSR,* movep X:M_HRX,Y:(r0)+ _load jmp next upload_end end signature.asc Description: This is a digitally signed message part
Re: anyone running a PS3
(d-k folks, please let me know if you're feeling spammed by the cross-posting) okay, reporting back in on this... using the 2.6.26.5 kernel from the debian kernel snapshot repo, the system successfully boots up! however, there seems to be another, perhaps more subtle problem lurking in this kernel too. the symptoms are a system which gradually slows down, to the point of being unresponsive and needing a hard-reboot, and individual processes hanging in an unkillable state. typically this takes about an hour or two. the first time it happened i was in the middle of installing about a gig of packages (apt-get install gnome...), another time it was while trying to play a video. occassionally kernel log messages pop up regarding what seems to be the wireless component of the gelic module (i'm not using it, but maybe n-m is tickling it), and sometimes specific proccesses (apt-get in the previous paragraph) will hang; several minutes after a kill -9 the kernel will issue some kind of message about the task not responding. sorry this isn't really specific, i didn't have any kind of console logging set up (i'll get a copy of it hte next time it happens). i'll also try installing some vanilla upstream kernels to see if they suffer from the same problems... sean On Sat, Oct 11, 2008 at 03:36:08PM -0400, Norberto Feliberty wrote: Date: Sat, 11 Oct 2008 11:10:44 +0200 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED]; debian-kernel@lists.debian.org Subject: Re: anyone running a PS3 (cc'ing debian-kernel now too, for some feedback) d-k folks: the issue is that the ps3 fails to boot with the latest lenny 2.6.26 kernels, due to what appears to be a kernel bug which has been fixed upstream). my original post: http://lists.debian.org/debian-powerpc/2008/10/msg00029.html so where was i... yes, it seems that it's in fact a kernel bug. i updated to the latest kboot, which also had the same problem booting the kernel. then googling for ps3 2.6.26 leads to the following: http://www.yellowdog-board.com/viewtopic.php?f=19t=4063start=0st=0sk=tsd=a (scroll down a bit searching for 2.6.26) which points to: http://www.gossamer-threads.com/lists/linux/kernel/972382 which mentions an obscure intterupt handling bug causing the problem, and which points to: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=de85422b94ddb23c021126815ea49414047c13dc which was accepted into the -stable queue for 2.6, which was then released as part of 2.6.26.6: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.26.y.git;a=commit;h=90e21dd5346538810cff7f5fa2d3b0ae4c88989d so thanks for the pointer. d-k folks: is there any feasibility for getting this fix into lenny, or am I just SoL? sean _ See how Windows connects the people, information, and fun that are part of your life. http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/ -- signature.asc Description: Digital signature
Bug#494007: binary firmware in drivers/char/drm/r128_cce.c
Here's a patch to make r128 use request_firmware. This is
compile-tested only as I don't have appropriate hardware. The firmware
file can be produced by writing the array as 32-bit little-endian
values. However, there is still a problem with its licence.
Ben.
diff --git a/drivers/char/drm/Kconfig b/drivers/char/drm/Kconfig
index 610d6fd..ea26dfd 100644
--- a/drivers/char/drm/Kconfig
+++ b/drivers/char/drm/Kconfig
@@ -26,6 +26,7 @@ config DRM_TDFX
config DRM_R128
tristate ATI Rage 128
depends on DRM PCI
+ select FW_LOADER
help
Choose this option if you have an ATI Rage 128 graphics card. If M
is selected, the module will be called r128. AGP support for
diff --git a/drivers/char/drm/r128_cce.c b/drivers/char/drm/r128_cce.c
index c31afbd..e29c082 100644
--- a/drivers/char/drm/r128_cce.c
+++ b/drivers/char/drm/r128_cce.c
@@ -29,6 +29,8 @@
*Gareth Hughes [EMAIL PROTECTED]
*/
+#include linux/firmware.h
+
#include drmP.h
#include drm.h
#include r128_drm.h
@@ -36,51 +38,6 @@
#define R128_FIFO_DEBUG0
-/* CCE microcode (from ATI) */
-static u32 r128_cce_microcode[] = {
- 0, 276838400, 0, 268449792, 2, 142, 2, 145, 0, 1076765731, 0,
- 1617039951, 0, 774592877, 0, 1987540286, 0, 2307490946U, 0,
- 599558925, 0, 589505315, 0, 596487092, 0, 589505315, 1,
- 11544576, 1, 206848, 1, 311296, 1, 198656, 2, 912273422, 11,
- 262144, 0, 0, 1, 33559837, 1, 7438, 1, 14809, 1, 6615, 12, 28,
- 1, 6614, 12, 28, 2, 23, 11, 18874368, 0, 16790922, 1, 409600, 9,
- 30, 1, 147854772, 16, 420483072, 3, 8192, 0, 10240, 1, 198656,
- 1, 15630, 1, 51200, 10, 34858, 9, 42, 1, 33559823, 2, 10276, 1,
- 15717, 1, 15718, 2, 43, 1, 15936948, 1, 570480831, 1, 14715071,
- 12, 322123831, 1, 33953125, 12, 55, 1, 33559908, 1, 15718, 2,
- 46, 4, 2099258, 1, 526336, 1, 442623, 4, 4194365, 1, 509952, 1,
- 459007, 3, 0, 12, 92, 2, 46, 12, 176, 1, 15734, 1, 206848, 1,
- 18432, 1, 133120, 1, 100670734, 1, 149504, 1, 165888, 1,
- 15975928, 1, 1048576, 6, 3145806, 1, 15715, 16, 2150645232U, 2,
- 268449859, 2, 10307, 12, 176, 1, 15734, 1, 15735, 1, 15630, 1,
- 15631, 1, 5253120, 6, 3145810, 16, 2150645232U, 1, 15864, 2, 82,
- 1, 343310, 1, 1064207, 2, 3145813, 1, 15728, 1, 7817, 1, 15729,
- 3, 15730, 12, 92, 2, 98, 1, 16168, 1, 16167, 1, 16002, 1, 16008,
- 1, 15974, 1, 15975, 1, 15990, 1, 15976, 1, 15977, 1, 15980, 0,
- 15981, 1, 10240, 1, 5253120, 1, 15720, 1, 198656, 6, 110, 1,
- 180224, 1, 103824738, 2, 112, 2, 3145839, 0, 536885440, 1,
- 114880, 14, 125, 12, 206975, 1, 33559995, 12, 198784, 0,
- 33570236, 1, 15803, 0, 15804, 3, 294912, 1, 294912, 3, 442370,
- 1, 11544576, 0, 811612160, 1, 12593152, 1, 11536384, 1,
- 14024704, 7, 310382726, 0, 10240, 1, 14796, 1, 14797, 1, 14793,
- 1, 14794, 0, 14795, 1, 268679168, 1, 9437184, 1, 268449792, 1,
- 198656, 1, 9452827, 1, 1075854602, 1, 1075854603, 1, 557056, 1,
- 114880, 14, 159, 12, 198784, 1, 1109409213, 12, 198783, 1,
- 1107312059, 12, 198784, 1, 1109409212, 2, 162, 1, 1075854781, 1,
- 1073757627, 1, 1075854780, 1, 540672, 1, 10485760, 6, 3145894,
- 16, 274741248, 9, 168, 3, 4194304, 3, 4209949, 0, 0, 0, 256, 14,
- 174, 1, 114857, 1, 33560007, 12, 176, 0, 10240, 1, 114858, 1,
- 33560018, 1, 114857, 3, 33560007, 1, 16008, 1, 114874, 1,
- 33560360, 1, 114875, 1, 33560154, 0, 15963, 0, 256, 0, 4096, 1,
- 409611, 9, 188, 0, 10240, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
-};
-
static int R128_READ_PLL(struct drm_device * dev, int addr)
{
drm_r128_private_t *dev_priv = dev-dev_private;
@@ -176,20 +133,36 @@ static int r128_do_wait_for_idle(drm_r128_private_t *
dev_priv)
*/
/* Load the microcode for the CCE */
-static void r128_cce_load_microcode(drm_r128_private_t * dev_priv)
+static int
+r128_cce_load_microcode(struct drm_device *dev, drm_r128_private_t *dev_priv)
{
- int i;
+ const struct firmware *fw;
+ const __le32 *microcode;
+ int rc, i;
#
DRM_DEBUG(\n);
+ rc = request_firmware(fw, r128/cce_ucode.bin, dev-pdev-dev);
+ if (rc)
+ return rc;
+ if (fw-size != 256 * 8) {
+ release_firmware(fw);
+ return -EINVAL;
+ }
+ microcode = (const __le32 *)fw-data;
+
r128_do_wait_for_idle(dev_priv);
R128_WRITE(R128_PM4_MICROCODE_ADDR, 0);
for (i = 0; i 256; i++) {
-
Bug#494009: binary firmware in drivers/char/drm/radeon_microcode.h
Here's a patch to radeon to make it use request_firmware. This is
compile-tested only, but I have hardware I can test on shortly. The
firmware files can be produced by writing the arrays as 32-bit
little-endian values. They should be suitable for inclusion in
firmware-nonfree, so I am including a patch for that as well.
Ben.
diff --git a/drivers/char/drm/Kconfig b/drivers/char/drm/Kconfig
index ea26dfd..17edd8a 100644
--- a/drivers/char/drm/Kconfig
+++ b/drivers/char/drm/Kconfig
@@ -35,6 +35,7 @@ config DRM_R128
config DRM_RADEON
tristate ATI Radeon
depends on DRM PCI
+ select FW_LOADER
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
diff --git a/drivers/char/drm/radeon_cp.c b/drivers/char/drm/radeon_cp.c
index e53158f..8408e34 100644
--- a/drivers/char/drm/radeon_cp.c
+++ b/drivers/char/drm/radeon_cp.c
@@ -29,14 +29,14 @@
*Gareth Hughes [EMAIL PROTECTED]
*/
+#include linux/firmware.h
+
#include drmP.h
#include drm.h
#include radeon_drm.h
#include radeon_drv.h
#include r300_reg.h
-#include radeon_microcode.h
-
#define RADEON_FIFO_DEBUG 0
static int radeon_do_cleanup_cp(struct drm_device * dev);
@@ -319,83 +319,71 @@ static void radeon_init_pipes(drm_radeon_private_t
*dev_priv)
* CP control, initialization
*/
+static const char *radeon_cp_family_name(drm_radeon_private_t * dev_priv)
+{
+ switch (dev_priv-flags RADEON_FAMILY_MASK) {
+ case CHIP_R100: case CHIP_RV100: case CHIP_RV200: case CHIP_RS100:
+ case CHIP_RS200:
+ return R100;
+ case CHIP_R200: case CHIP_RV250: case CHIP_RV280: case CHIP_RS300:
+ return R200;
+ case CHIP_R300: case CHIP_R350: case CHIP_RV350: case CHIP_RV380:
+ case CHIP_RS480:
+ return R300;
+ case CHIP_R420: case CHIP_RV410:
+ return R400;
+ case CHIP_RS690:
+ return RS690;
+ case CHIP_RV515: case CHIP_R520: case CHIP_RV530: case CHIP_R580:
+ case CHIP_RV560: case CHIP_RV570:
+ return R500;
+ default:
+ WARN_ON(1); /* new chip needs a name */
+ return ;
+ }
+}
+
/* Load the microcode for the CP */
static void radeon_cp_load_microcode(drm_radeon_private_t * dev_priv)
{
+ const __le32 *microcode;
int i;
DRM_DEBUG(\n);
radeon_do_wait_for_idle(dev_priv);
+ DRM_INFO(Loading %s Microcode\n, radeon_cp_family_name(dev_priv));
+ microcode = (const __le32 *)dev_priv-microcode-data;
RADEON_WRITE(RADEON_CP_ME_RAM_ADDR, 0);
- if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R100) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV100) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV200) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RS100) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RS200)) {
- DRM_INFO(Loading R100 Microcode\n);
- for (i = 0; i 256; i++) {
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAH,
-R100_cp_microcode[i][1]);
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAL,
-R100_cp_microcode[i][0]);
- }
- } else if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R200) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV250) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV280) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RS300)) {
- DRM_INFO(Loading R200 Microcode\n);
- for (i = 0; i 256; i++) {
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAH,
-R200_cp_microcode[i][1]);
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAL,
-R200_cp_microcode[i][0]);
- }
- } else if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R300) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R350) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV350) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV380) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RS480)) {
- DRM_INFO(Loading R300 Microcode\n);
- for (i = 0; i 256; i++) {
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAH,
-R300_cp_microcode[i][1]);
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAL,
-R300_cp_microcode[i][0]);
- }
- } else if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R420) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV410)) {
- DRM_INFO(Loading R400 Microcode\n);
-
Bug#494010: Source for dsp56k firmware
On Sun, Oct 12, 2008 at 08:10:53PM +0100, Ben Hutchings wrote: Here is the assembly-language source for the firmware, licenced under GPLv2. Very nice! Where did you find it? Adding this to the kernel source package should fix this bug. Actually, it should be assembled and used. AFAICT this is for an m68k processor. I suppose we have a command to assemble this code in binutils-multiarch or so? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501153: binary firmware in drivers/net/tehuti_fw.h
Here's a patch for tehuti to make it use request_firmware. This is
compile-tested only. The firmware file can be produced by writing out
the array s_loadFirm as 32-bit little-endian values. However, the
licence remains a problem.
Ben.
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 3e433cb..9e1a73c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2569,6 +2569,7 @@ config MLX4_DEBUG
config TEHUTI
tristate Tehuti Networks 10G Ethernet
depends on PCI
+ select FW_LOADER
help
Tehuti Networks 10G Ethernet NIC
diff --git a/drivers/net/tehuti.c b/drivers/net/tehuti.c
index 432e837..3f732eb 100644
--- a/drivers/net/tehuti.c
+++ b/drivers/net/tehuti.c
@@ -63,7 +63,6 @@
*/
#include tehuti.h
-#include tehuti_fw.h
static struct pci_device_id __devinitdata bdx_pci_tbl[] = {
{0x1FC9, 0x3009, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
@@ -319,28 +318,41 @@ static int bdx_poll(struct napi_struct *napi, int budget)
static int bdx_fw_load(struct bdx_priv *priv)
{
+ const struct firmware *fw = NULL;
int master, i;
+ int rc;
ENTER;
master = READ_REG(priv, regINIT_SEMAPHORE);
if (!READ_REG(priv, regINIT_STATUS) master) {
- bdx_tx_push_desc_safe(priv, s_firmLoad, sizeof(s_firmLoad));
+ rc = request_firmware(fw, tehuti/firmware.bin,
priv-pdev-dev);
+ if (rc)
+ goto out;
+ bdx_tx_push_desc_safe(priv, fw-data, fw-size);
mdelay(100);
}
for (i = 0; i 200; i++) {
- if (READ_REG(priv, regINIT_STATUS))
- break;
+ if (READ_REG(priv, regINIT_STATUS)) {
+ rc = 0;
+ goto out;
+ }
mdelay(2);
}
+ rc = -EIO;
+out:
+ if (fw)
+ release_firmware(fw);
if (master)
WRITE_REG(priv, regINIT_SEMAPHORE, 1);
- if (i == 200) {
+ if (rc) {
ERR(%s: firmware loading failed\n, priv-ndev-name);
- DBG(VPC = 0x%x VIC = 0x%x INIT_STATUS = 0x%x i=%d\n,
- READ_REG(priv, regVPC),
- READ_REG(priv, regVIC), READ_REG(priv, regINIT_STATUS), i);
- RET(-EIO);
+ if (rc == -EIO)
+ DBG(VPC = 0x%x VIC = 0x%x INIT_STATUS = 0x%x i=%d\n,
+ READ_REG(priv, regVPC),
+ READ_REG(priv, regVIC),
+ READ_REG(priv, regINIT_STATUS), i);
+ RET(rc);
} else {
DBG(%s: firmware loading success\n, priv-ndev-name);
RET(0);
@@ -618,13 +630,6 @@ err:
RET(rc);
}
-static void __init bdx_firmware_endianess(void)
-{
- int i;
- for (i = 0; i ARRAY_SIZE(s_firmLoad); i++)
- s_firmLoad[i] = CPU_CHIP_SWAP32(s_firmLoad[i]);
-}
-
static int bdx_range_check(struct bdx_priv *priv, u32 offset)
{
return (offset (u32) (BDX_REGS_SIZE / priv-nic-port_num)) ?
@@ -2498,7 +2503,6 @@ static void __init print_driver_id(void)
static int __init bdx_module_init(void)
{
ENTER;
- bdx_firmware_endianess();
init_txd_sizes();
print_driver_id();
RET(pci_register_driver(bdx_pci_driver));
@@ -2518,3 +2522,4 @@ module_exit(bdx_module_exit);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(BDX_DRV_DESC);
+MODULE_FIRMWARE(tehuti/firmware.bin);
diff --git a/drivers/net/tehuti.h b/drivers/net/tehuti.h
index efd170f..b9acb3f 100644
--- a/drivers/net/tehuti.h
+++ b/drivers/net/tehuti.h
@@ -30,6 +30,7 @@
#include linux/version.h
#include linux/interrupt.h
#include linux/vmalloc.h
+#include linux/firmware.h
#include asm/byteorder.h
/* Compile Time Switches */
--- END ---
signature.asc
Description: This is a digitally signed message part
Bug#501152: binary firmware in drivers/net/starfire_firmware.h
Here's a patch for starfire to make it use request_firmware. This is compile-tested only. The firmware files can be produced by writing out the firmware_rx and firmware_tx arrays as 32-bit little-endian values. However, the licence remains a problem. Ben. diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 4a12477..3e433cb 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1306,6 +1306,7 @@ config ADAPTEC_STARFIRE depends on NET_PCI PCI select CRC32 select MII + select FW_LOADER help Say Y here if you have an Adaptec Starfire (or DuraLAN) PCI network adapter. The DuraLAN chip is used on the 64 bit PCI boards from diff --git a/drivers/net/starfire.c b/drivers/net/starfire.c index 7b7b171..73394d9 100644 --- a/drivers/net/starfire.c +++ b/drivers/net/starfire.c @@ -42,11 +42,11 @@ #include linux/mii.h #include linux/if_vlan.h #include linux/mm.h +#include linux/firmware.h #include asm/processor.h /* Processor type for cache alignment. */ #include asm/uaccess.h #include asm/io.h -#include starfire_firmware.h /* * The current frame processor firmware fails to checksum a fragment * of length 1. If and when this is fixed, the #define below can be removed. @@ -224,6 +224,8 @@ MODULE_AUTHOR(Donald Becker [EMAIL PROTECTED]); MODULE_DESCRIPTION(Adaptec Starfire Ethernet driver); MODULE_LICENSE(GPL); MODULE_VERSION(DRV_VERSION); +MODULE_FIRMWARE(starfire/gfp_rx.bin); +MODULE_FIRMWARE(starfire/gfp_tx.bin); module_param(max_interrupt_work, int, 0); module_param(mtu, int, 0); @@ -948,12 +950,21 @@ static int netdev_open(struct net_device *dev) void __iomem *ioaddr = np-base; int i, retval; size_t tx_done_q_size, rx_done_q_size, tx_ring_size, rx_ring_size; + const struct firmware *fw_rx, *fw_tx; + const __le32 *fw_data; /* Do we ever need to reset the chip??? */ - retval = request_irq(dev-irq, intr_handler, IRQF_SHARED, dev-name, dev); + retval = request_firmware(fw_rx, starfire/gfp_rx.bin, np-pci_dev-dev); if (retval) return retval; + retval = request_firmware(fw_tx, starfire/gfp_tx.bin, np-pci_dev-dev); + if (retval) + goto out_release_fw_rx; + + retval = request_irq(dev-irq, intr_handler, IRQF_SHARED, dev-name, dev); + if (retval) + goto out_release_fw_tx; /* Disable the Rx and Tx, and reset the chip. */ writel(0, ioaddr + GenCtrl); @@ -1084,10 +1095,12 @@ static int netdev_open(struct net_device *dev) #endif /* VLAN_SUPPORT */ /* Load Rx/Tx firmware into the frame processors */ - for (i = 0; i FIRMWARE_RX_SIZE * 2; i++) - writel(firmware_rx[i], ioaddr + RxGfpMem + i * 4); - for (i = 0; i FIRMWARE_TX_SIZE * 2; i++) - writel(firmware_tx[i], ioaddr + TxGfpMem + i * 4); + fw_data = (const __le32 *)fw_rx-data; + for (i = 0; i fw_rx-size / 4; i++) + writel(le32_to_cpu(fw_data[i]), ioaddr + RxGfpMem + i * 4); + fw_data = (const __le32 *)fw_tx-data; + for (i = 0; i fw_tx-size / 4; i++) + writel(le32_to_cpu(fw_data[i]), ioaddr + TxGfpMem + i * 4); if (enable_hw_cksum) /* Enable the Rx and Tx units, and the Rx/Tx frame processors. */ writel(TxEnable|TxGFPEnable|RxEnable|RxGFPEnable, ioaddr + GenCtrl); @@ -1099,7 +1112,11 @@ static int netdev_open(struct net_device *dev) printk(KERN_DEBUG %s: Done netdev_open().\n, dev-name); - return 0; +out_release_fw_tx: + release_firmware(fw_tx); +out_release_fw_rx: + release_firmware(fw_rx); + return retval; } --- END --- signature.asc Description: This is a digitally signed message part
Bug#494009: binary firmware in drivers/char/drm/radeon_microcode.h
However, you should probably use this patch and firmware format instead: http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=3a911a216742e4ab998f3281409d46a62f252716 Ben. signature.asc Description: This is a digitally signed message part
Bug#501153: binary firmware in drivers/net/tehuti_fw.h
You could use this similar patch instead: http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=e41f3e5f8c5110871e376a2566b8eea2932b813b Ben. signature.asc Description: This is a digitally signed message part
Bug#498631: binary firmware in drivers/net/cassini.h
You could use this patch and firmware format instead: http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=5263b94d83666854240d254852dd44309c436e25 Ben. signature.asc Description: This is a digitally signed message part
Processed: tagging 494009
Processing commands for [EMAIL PROTECTED]: tags 494009 patch Bug#494009: binary firmware in drivers/char/drm/radeon_microcode.h Tags were: help Tags added: patch End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501152: binary firmware in drivers/net/starfire_firmware.h
You could use this patch and firmware format instead: http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=6963b36bfb1f171ae8ea4884e239bdccc5f47266 Ben. signature.asc Description: This is a digitally signed message part
Bug#501153: Tehuti driver and firmware distribution for Linux
I am writing as a member of the Debian project, which distributes a version of Linux. The project is attempting to resolve the licencing of firmware used with Linux. The following may require attention by your legal department. Linux includes a driver and firmware which are listed as copyright of Tehuti Networks and licenced under the GNU General Public Licence (GPL). Thank you for supporting Linux and free software. Unfortunately, applying the GPL to the firmware is problematic, because you distribute it in binary (or equivalent) form, and not the source code that your programmers used to create it. The GPL states that anyone redistributing a work that it covers must also offer to distribute the source code. This means that strictly speaking no-one outside Tehuti Networks is allowed to distribute the firmware, which I assume was not your intent. Please can you clarify the licence for the firmware, and preferably issue a new licence that clearly allows Debian and others to distribute the firmware. Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 494010
Processing commands for [EMAIL PROTECTED]: tags 494010 patch Bug#494010: binary firmware in drivers/char/dsp56k.c Tags were: patch fixed-upstream help Tags added: patch End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 494308
Processing commands for [EMAIL PROTECTED]: tags 494308 patch Bug#494308: binary firmware in drivers/net/e100.c Tags were: help Tags added: patch End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498631: Sun GigaSwift driver and firmware distribution for Linux
I am writing as a member of the Debian project, which distributes a version of Linux. The project is attempting to resolve the licencing of firmware used with Linux. Linux includes a driver (cassini) and firmware for GigaSwift NICs which are listed as copyright of Sun Microsystems and licenced under the GNU General Public Licence (GPL). Thank you for supporting Linux and free software. Unfortunately, applying the GPL to the firmware is problematic, because you distribute it in binary (or equivalent) form, and not the source code that your programmers used to create it. The GPL states that anyone redistributing a work that it covers must also offer to distribute the source code. This means that strictly speaking no-one outside Sun Microsystems is allowed to distribute the firmware, which I assume was not your intent. Please can you clarify the licence for the firmware, and preferably issue a new licence that clearly allows Debian and others to distribute the firmware. Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494007: binary firmware in drivers/char/drm/r128_cce.c
I asked Dave Airlie about this: 23:36 bwh airlied: Do you know who might be a good person to write to at ATI/AMD about the licence for firmware in r128? 23:48 airlied bwh: what license you want it under? its already MIT licensed. 23:50 bwh airlied: Is it? Thing is, r128_cce.c doesn't have any ATI copyright notice on it. 23:51 airlied bwh: fail.. it probably should have, its still MIT licensed though. 23:52 bwh So would someone at ATI be able to confirm that? 23:53 airlied well the r128_cce.c has the MIT license on top 23:53 airlied I'm just looking to see if I have the original DDK release. 23:55 bwh airlied: cheers 23:56 airlied so the original table was just released under NDA, with permission to reuse in open source. 23:58 bwh Funny sort of NDA ;-) Do you have some legally meaningful statement of the permission that you could forward? 23:58 airlied bwh: why funny? 23:58 airlied I get lots of NDAs like that. 23:59 airlied nope I've gotten nothing real, I doubt anyone in AMD has either, this is like a 10 year old part. I don't know if this is sufficient assurance of its licence. Ben. signature.asc Description: This is a digitally signed message part
Bug#501152: binary firmware in drivers/net/starfire_firmware.h
FreeBSD appears to have copied the proper copyright notices into their versions of the firmware: http://fxr.watson.org/fxr/source/dev/sf/starfire_rx.h http://fxr.watson.org/fxr/source/dev/sf/starfire_tx.h (c)2001 Adaptec, Inc. By using this software you agree that it is licensed to you AS IS and that Adaptec makes no warranties, express or implied, regarding the Software. Any redistribution of this Software must include this disclaimer and copyright notice. So this ought to be OK for firmware-nonfree. Ben. signature.asc Description: This is a digitally signed message part
Processed: tagging 501152
Processing commands for [EMAIL PROTECTED]: tags 501152 patch Bug#501152: binary firmware in drivers/net/starfire_firmware.h There were no tags set. Tags added: patch End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501153: Tehuti driver and firmware distribution for Linux
I am writing as a member of the Debian project, which distributes a version of Linux. The project is attempting to resolve the licencing of firmware used with Linux. The following may require attention by your legal department. Linux includes a driver and firmware which are listed as copyright of Tehuti Networks and licenced under the GNU General Public Licence (GPL). Thank you for supporting Linux and free software. Unfortunately, applying the GPL to the firmware is problematic, because you distribute it in binary (or equivalent) form, and not the source code that your programmers used to create it. The GPL states that anyone redistributing a work that it covers must also offer to distribute the source code. This means that strictly speaking no-one outside Tehuti Networks is allowed to distribute the firmware, which I assume was not your intent. Please can you clarify the licence for the firmware, and preferably issue a new licence that clearly allows Debian and others to distribute the firmware. Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444880: Re-opening awaiting fixed-version info
Hi! I'll be re-opening this in a short while while waiting for information about which kernel version this bug has been fixed in. Without knowing which kernel version has the fix this is really hard for me to verify. If this has not been fixed, feel free to just leave this bug open until it is. Regards //Johan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
