Bug#886662: wireguard-dkms should depend on libelf-dev
Daniel Kahn Gillmor wrote: > make: Entering directory '/usr/src/linux-headers-4.14.0-3-amd64' > /usr/src/linux-headers-4.14.0-3-common/Makefile:947: *** "Cannot generate ORC > metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel > or elfutils-libelf-devel". Stop. > Makefile:146: recipe for target 'sub-make' failed > make[1]: *** [sub-make] Error 2 > Makefile:8: recipe for target 'all' failed > make: *** [all] Error 2 > make: Leaving directory '/usr/src/linux-headers-4.14.0-3-amd64' > 0 root@sid:~# > > I'll fix this shortly. Hi, Daniel: You may want to hold off on fixing this in wireguard. It looks like this is a regression in src:linux (#886474). Given this failure is coming from the kernel build system apparently before the module itself even starts building, it would seem to affect all out-of-tree kernel module packages. -- Robert Edmonds edmo...@debian.org
Bug#860335: linux: [armhf] ahci_mvebu module is missing from sata-modules udeb
Package: linux Version: 4.9.18-1 Severity: normal Tags: d-i patch Hi, The sata-modules udeb on armhf is missing the "ahci_mvebu" module. This prevents, e.g., installing Debian to an mSATA SSD installed in a Marvell Armada 385 SoC based system like the Turris Omnia. I was able to complete an install using the d-i stretch rc3 release after manually copying ahci_mvebu.ko to the running installer environment and modprobe'ing it, so I think the attached patch will fix this problem. (See #860286 for the installation report.) Thanks! -- Robert Edmonds edmo...@debian.org >From efa1c34a255f9ead2dd3591bb076b5b9d9c05110 Mon Sep 17 00:00:00 2001 From: Robert Edmonds <edmo...@debian.org> Date: Fri, 14 Apr 2017 12:55:13 -0400 Subject: [PATCH] [armhf] sata-modules: Add module required for Turris Omnia mSATA --- debian/installer/armhf/modules/armhf-armmp/sata-modules | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/installer/armhf/modules/armhf-armmp/sata-modules b/debian/installer/armhf/modules/armhf-armmp/sata-modules index 70d5e3674..a1b457370 100644 --- a/debian/installer/armhf/modules/armhf-armmp/sata-modules +++ b/debian/installer/armhf/modules/armhf-armmp/sata-modules @@ -3,6 +3,7 @@ ahci_platform ahci_imx ahci_sunxi ahci_tegra +ahci_mvebu sata_highbank # SATA PHYs -- 2.11.0
Bug#595717: closed by Ben Hutchings b...@decadent.org.uk (Re: please enable PPS_CLIENT_LDISC and PPS_CLIENT_KTIMER)
Debian Bug Tracking System wrote: config PPS_CLIENT_KTIMER tristate Kernel timer client (Testing client, use for debug) help If you say yes here you get support for a PPS debugging client which uses a kernel timer to generate the PPS signal. This driver can also be built as a module. If so, the module will be called pps-ktimer. I have not enabled this as it's a debug option only. my understanding is that this option is for debugging userspace applications which use the kernel PPS interface. not for debugging the kernel PPS implementation. -- Robert Edmonds edmo...@debian.org -- 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/20110312233648.ga25...@mycre.ws
Bug#595717: please enable PPS_CLIENT_LDISC and PPS_CLIENT_KTIMER
Package: linux-2.6 Version: 2.6.35-1~experimental.2 Severity: wishlist hi, i'd like to request that the PPS client modules be enabled: $ grep CONFIG_PPS_CLIENT /boot/config-2.6.35-trunk-amd64 # CONFIG_PPS_CLIENT_KTIMER is not set # CONFIG_PPS_CLIENT_LDISC is not set $ the current linux-image packages ship with CONFIG_PPS=m set, but unfortunately this is a bit useless without the client modules as well: config PPS_CLIENT_KTIMER tristate Kernel timer client (Testing client, use for debug) help If you say yes here you get support for a PPS debugging client which uses a kernel timer to generate the PPS signal. This driver can also be built as a module. If so, the module will be called pps-ktimer. config PPS_CLIENT_LDISC tristate PPS line discipline depends on PPS help If you say yes here you get support for a PPS source connected with the CD (Carrier Detect) pin of your serial port. PPS_CLIENT_LDISC in particular is needed if you want to attach a stratum-0 NTP time source (GPS with pulse-per-second line attached to the CD pin) to a debian host, e.g.: http://time.qnan.org/ http://wiki.enneenne.com/index.php/LinuxPPS_installation an almost identical bug was reported in the fedora bugzilla, btw: https://bugzilla.redhat.com/show_bug.cgi?id=619392 thanks! -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#578129: please apply skip sense logging for some ATA PASS-THROUGH cdbs from 2.6.33
Package: linux-2.6
Version: 2.6.32-11
Severity: normal
Tags: patch
hi,
when SATA drives are attached to SAS controllers and used in ATA
pass-through mode, many operations cause alarming but harmless messages
(though it may not be immediately obvious to the user that they are
harmless) to be written to the kernel log, e.g.:
[1381579.095459] sd 8:0:23:0: [sdx] Sense Key : Recovered Error [current]
[descriptor]
[1381579.095518] Descriptor sense data with sense descriptors (in hex):
[1381579.095549] 72 01 00 1d 00 00 00 0e 09 0c 00 00 00 00 00 00
[1381579.095614] 00 4f 00 c2 00 50
[1381579.095654] sd 8:0:23:0: [sdx] Add. Sense: ATA pass through information
available
i see these types of messages at boot as well as periodically due to the
use of smartmontools. if you have a lot of disks your kernel log will
be spammed.
can you apply commit e7efe5932b1d3916c79326a4221693ea90a900e2 from
2.6.33 to suppress these messages?
thanks.
--
Robert Edmonds
edmo...@debian.org
From e7efe5932b1d3916c79326a4221693ea90a900e2 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert dgilb...@interlog.com
Date: Sun, 3 Jan 2010 13:51:15 -0500
Subject: [PATCH] [SCSI] skip sense logging for some ATA PASS-THROUGH cdbs
Further to the lsml thread titled:
does scsi_io_completion need to dump sense data for ata pass through (ck_cond =
1) ?
This is a patch to skip logging when the sense data is
associated with a SENSE_KEY of RECOVERED_ERROR and the
additional sense code is ATA PASS-THROUGH INFORMATION
AVAILABLE. This only occurs with the SAT ATA PASS-THROUGH
commands when CK_COND=1 (in the cdb). It indicates that
the sense data contains ATA registers.
Smartmontools uses such commands on ATA disks connected via
SAT. Periodic checks such as those done by smartd cause
nuisance entries into logs that are:
- neither errors nor warnings
- pointless unless the cdb that caused them are also logged
Signed-off-by: Douglas Gilbert dgilb...@interlog.com
Signed-off-by: James Bottomley james.bottom...@suse.de
---
drivers/scsi/scsi_lib.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index c664242..5697709 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -773,8 +773,14 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
* we already took a copy of the original into rq-errors which
* is what gets returned to the user
*/
- if (sense_valid sshdr.sense_key == RECOVERED_ERROR) {
- if (!(req-cmd_flags REQ_QUIET))
+ if (sense_valid (sshdr.sense_key == RECOVERED_ERROR)) {
+ /* if ATA PASS-THROUGH INFORMATION AVAILABLE skip
+ * print since caller wants ATA registers. Only occurs on
+ * SCSI ATA PASS_THROUGH commands when CK_COND=1
+ */
+ if ((sshdr.asc == 0x0) (sshdr.ascq == 0x1d))
+ ;
+ else if (!(req-cmd_flags REQ_QUIET))
scsi_print_sense(, cmd);
result = 0;
/* BLOCK_PC may have set error */
--
1.7.0.4
signature.asc
Description: Digital signature
Bug#547546: kernel BUG at net/ipv6/ip6_output.c:699
Package: linux-image-2.6.18-6-mckinley Version: 2.6.18.dfsg.1-24etch3 hi, i've encountered a problem with BIND9 running on oldstable. we're running native IPv6 and serving DNSSEC-signed zones, so the problem appears to be related to IPv6/UDP fragmentation. when the problem manifests itself the named process stops serving DNS requests and the process becomes unkillable. i am fairly certain that this is the same bug: http://www.mail-archive.com/net...@vger.kernel.org/msg21249.html in particular, see: http://www.mail-archive.com/net...@vger.kernel.org/msg23619.html the bug fix (132a55f3c5c0b1a364d32f65595ad8838c30a60e) was merged to 2.6.19 but never added to 2.6.18. it would probably be a good idea to add this fix in an oldstable kernel update. here is the BUG() dmesg output: kernel BUG at net/ipv6/ip6_output.c:699! named[1992]: bugcheck! 0 [1] Modules linked in: button xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables dm_snapshot dm_mirror dm_mod ipv6 loop shpchp pci_hotplug ext3 jbd mbcache ide_cd cdrom generic mptspi mptscsih ohci_hcd ehci_hcd mptbase cmd64x cciss scsi_transport_spi usbcore ide_core scsi_mod e1000 thermal processor fan Pid: 1992, CPU 0, comm:named psr : 101008526030 ifs : 8916 ip : [a00204195ee0]Not tainted ip is at ip6_output+0x5e0/0x1400 [ipv6] unat: pfs : 0916 rsc : 0003 rnat: bsps: pr : 00569959 ldrs: ccv : fpsr: 0009804c8a70033f csd : ssd : b0 : a00204195ee0 b6 : a001000b30a0 b7 : a00100283c40 f6 : 1003e00a0 f7 : 1003e20c49ba5e353f7cf f8 : 1003e04e2 f9 : 1003e0fa0 f10 : 1003e3b9aca00 f11 : 1003e431bde82d7b634db r1 : a001008db0e0 r2 : 41c8 r3 : a0010068cf38 r8 : 002c r9 : r10 : a001006f3350 r11 : 4000 r12 : e040f9117aa0 r13 : e040f911 r14 : 4000 r15 : a0010068cf38 r16 : a0010068cf40 r17 : 4000 r18 : e040f9110fd4 r19 : r20 : r21 : r22 : 0004 r23 : r24 : e040f9110fd4 r25 : 0750 r26 : 0730 r27 : 0073 r28 : 0073 r29 : 0027ffd8 r30 : 0027ffd8 r31 : 27d8 Call Trace: [a00100012f20] show_stack+0x40/0xa0 sp=e040f9117630 bsp=e040f9111608 [a00100013820] show_regs+0x840/0x880 sp=e040f9117800 bsp=e040f91115a8 [a00100034420] die+0x1c0/0x2c0 sp=e040f9117800 bsp=e040f9111560 [a00100034570] die_if_kernel+0x50/0x80 sp=e040f9117820 bsp=e040f9111530 [a00100035cb0] ia64_bad_break+0x270/0x4a0 sp=e040f9117820 bsp=e040f9111508 [a001bc40] ia64_leave_kernel+0x0/0x280 sp=e040f91178d0 bsp=e040f9111508 [a00204195ee0] ip6_output+0x5e0/0x1400 [ipv6] sp=e040f9117aa0 bsp=e040f9111458 [a002041979c0] ip6_push_pending_frames+0x940/0xb80 [ipv6] sp=e040f9117ab0 bsp=e040f9111408 [a002041c59e0] udp_v6_push_pending_frames+0x6a0/0x700 [ipv6] sp=e040f9117ae0 bsp=e040f91113b8 [a002041c8ad0] udpv6_sendmsg+0xed0/0x14a0 [ipv6] sp=e040f9117ae0 bsp=e040f9111330 [a0010047b810] inet_sendmsg+0xd0/0x100 sp=e040f9117b60 bsp=e040f91112f8 [a001003add70] sock_sendmsg+0x1f0/0x240 sp=e040f9117b60 bsp=e040f91112c0 [a001003b2960] sys_sendmsg+0x4a0/0x5a0 sp=e040f9117cc0 bsp=e040f9111228 [a001baa0] ia64_ret_from_syscall+0x0/0x20 sp=e040f9117e30 bsp=e040f9111228 [a0010620] __start_ivt_text+0x00010620/0x400 sp=e040f9118000 bsp=e040f9111228 -- Robert Edmonds edmo...@debian.org From 132a55f3c5c0b1a364d32f65595ad8838c30a60e Mon Sep 17 00:00:00 2001 From: Herbert Xu herb...@gondor.apana.org.au Date: Tue, 3 Oct 2006 14:34:00 -0700 Subject: [PATCH] [UDP6]: Fix flowi clobbering The udp6_sendmsg function uses a shared buffer to store the flow without taking any locks. This leads to races with SMP. This patch moves the flowi object onto the stack. Signed-off-by: Herbert Xu herb...@gondor.apana.org.au Acked-by: James Morris jmor...@namei.org Signed-off-by: David S. Miller da...@davemloft.net --- net/ipv6/udp.c | 62 1 files changed, 31
Bug#405810: Please provide package with vmlinuX, similar to kernel-debuginfo on redhat
Ping. Bastian Blank wrote: On Sat, Jan 06, 2007 at 02:50:46PM +0100, Philippe Teuwen wrote: To use oprofile with kernel profiling enabled, we need the uncompressed version of the kernel image, vmlinux. Use gunzip to get them (at least for architectures which simply compresses it with gzip). Some architectures also uses uncompressed files. This is not the case on at least amd64/i386. I saw on http://bonglonglong.com/2006/12/06/oprofile-kernel-images-and-innodb-oh-my/ that this is much easier on redhat which features a package called kernel-debuginfo I don't see such a package in the development fedora tree, please provide more informations. So could we also have sth like linux-debuginfo-2.6.18-1-686_i386.deb ? What should it contain? Only the uncompressed image? Or the unstripped? The uncompressed, unstripped vmlinux file at the top of the upstream linux build tree. For amd64 it is this file in the linux-2.6 build tree: [EMAIL PROTECTED]:~/src/linux/linux-2.6$ file linux-2.6-2.6.23/debian/build/build_amd64_none_amd64/vmlinux linux-2.6-2.6.23/debian/build/build_amd64_none_amd64/vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped The later is not possible for size constraints. Why? [EMAIL PROTECTED]:~/src/linux/linux-2.6$ ls -1sh linux-2.6-2.6.23/debian/build/build_amd64_none_amd64/vmlinux 5.0M linux-2.6-2.6.23/debian/build/build_amd64_none_amd64/vmlinux* -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
Faidon Liambotis wrote: Robert Edmonds wrote: Any modification to the tg3 driver to produce a GR 2006-004 compliant driver would have to diverge from the kernel team's patch acceptance guidelines[0] since upstream is intransigent[1] on making tg3 firmware-free or firmware-optional. The kernel team does not appear to be interested in maintaining such a driver, and it appears future linux kernel source packages will be patched[2] to simply remove the blobs of firmware (I don't know why the driver isn't simply removed entirely since the result does not compile). This seems totally inappropriate. If the driver includes non-free firmwares these should be removed or split up from the driver source, not remove the driver entirely. If what you say is right, the driver *works* for most of the hardware without non-free blobs. Therefore, I can't understand how removing the driver serves our users. That is why I said appear, since I hope that the kernel team has plans for the driver beyond simply eliding it. (I'd like to point out that the equivalent FreeBSD if_bge driver has no firmware blobs.) Any rationale behind that decision? I feel like I'm arguing for something completely obvious... The only rationale for removing the *firmware* is compliance with GR 2006-004... -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
On 2007-10-10, Bastian Blank [EMAIL PROTECTED] wrote:
The attached patch should apply on the pruned version.
Applies but does not compile:
tg3.c: In function âtg3_reset_hwâ:
tg3.c:5399: error: âTG3_TSO5_FW_TEXT_LENâ undeclared (first use in this
function)
tg3.c:5399: error: (Each undeclared identifier is reported only once
tg3.c:5399: error: for each function it appears in.)
tg3.c:5400: error: âTG3_TSO5_FW_RODATA_LENâ undeclared (first use in this
function)
tg3.c:5401: error: âTG3_TSO5_FW_DATA_LENâ undeclared (first use in this
function)
tg3.c:5402: error: âTG3_TSO5_FW_SBSS_LENâ undeclared (first use in this
function)
tg3.c:5403: error: âTG3_TSO5_FW_BSS_LENâ undeclared (first use in this
function)
The offending code is:
/* Initialize MBUF/DESC pool. */
if (tp-tg3_flags2 TG3_FLG2_5750_PLUS) {
/* Do nothing. */
} else if (GET_ASIC_REV(tp-pci_chip_rev_id) != ASIC_REV_5705) {
[...]
}
else if (tp-tg3_flags2 TG3_FLG2_TSO_CAPABLE) {
int fw_len;
fw_len = (TG3_TSO5_FW_TEXT_LEN +
TG3_TSO5_FW_RODATA_LEN +
TG3_TSO5_FW_DATA_LEN +
TG3_TSO5_FW_SBSS_LEN +
TG3_TSO5_FW_BSS_LEN);
fw_len = (fw_len + (0x80 - 1)) ~(0x80 - 1);
tw32(BUFMGR_MB_POOL_ADDR,
NIC_SRAM_MBUF_POOL_BASE5705 + fw_len);
tw32(BUFMGR_MB_POOL_SIZE,
NIC_SRAM_MBUF_POOL_SIZE5705 - fw_len - 0xa00);
}
--
Robert Edmonds
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmwares left
On 2007-09-25, Frederik Schueler [EMAIL PROTECTED] wrote: As for the rest: our priority is free software, who cares about users? tg3: Drop. The firmware should be pruned and the driver deactivated until someone shows up with a patch upstream accepts. Upstream is still hostile to any decoupling of firmware from the tg3 driver. Any functional free tg3 driver will have to come from Debian. (I just checked and the equivalent if_bge driver in FreeBSD is devoid of firmware blobs.) - Forwarded message from David Miller [EMAIL PROTECTED] - From: David Miller [EMAIL PROTECTED] Subject: Re: tg3 and request_firmware() Date: Sat, 29 Sep 2007 00:00:18 -0700 (PDT) From: Robert Edmonds [EMAIL PROTECTED] Date: Sat, 29 Sep 2007 01:40:35 -0400 Due to the Free software interpretation that has won out among voting Debian developers, the tg3 driver is to be removed[0] from Debian's 2.6.23 kernel. I do not agree with this interpretation and am very interested in seeing Debian not alienate users by breaking functioning drivers. Unfortunately the eventual removal of all non-free firmware from the Debian kernel has been in the plans for a long time and it seems far too late to reverse this decision. Debian therefore will become even more irrelevant than it already is. * There is a firmware fix necessary for 5701a0 chipsets to operate, but this is a very old, uncommon chipset. And what will you do when we come across a device which has a common variant which requires a firmware fix to operate correctly? I really don't agree with this approach to handling things, it's a slippery slope down which we end up with a non-functional kernel by default, sorry. Theses firmware images are part of the driver and are absolutely required for correct functionality in many cases. You can paper around cases like tg3 but you will not be able to do this across the board and it will in fact lead to hurting users. The time already wasted discussing this issue already has hurt users, in fact. I could be doing much more productive things than constantly saying no to this request. - End forwarded message - -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmwares left
On 2007-09-27, Manoj Srivastava [EMAIL PROTECTED] wrote:
On Tue, 25 Sep 2007 21:08:45 +0200, Frederik Schueler [EMAIL PROTECTED]
said:
tg3: Drop. The firmware should be pruned and the driver deactivated
until someone shows up with a patch upstream accepts.
While I am a user of this driver (my laptop came with a broadcom
gigabit card), I do appreciate your caring for user freedoms and
dropping this driver.
thanks for doing the right thing, even if it means I can't use
lan0.
This is ridiculous. Upstream is hostile to the idea of splitting out
tg3 firmware, and the vast majority of tg3 hardware works fine without
TSO. I'm not sure, but I think recent versions of the 57xx chips even
come with TSO firmware embedded in the device.
Manoj, unless your chipset is an ancient 5701 rev a0, it will work fine
without kernel-supplied firmware.
Why can't something like the following patch be applied?
http://people.debian.org/~edmonds/tg3/tg3_firmware_removal.diff
linux-source-2.6.23-rc5/drivers/net/tg3.c | 832 --
1 file changed, 10 insertions(+), 822 deletions(-)
--- linux-source-2.6.23-rc5/drivers/net/tg3.c.orig 2007-09-27
15:49:50.713859274 -0400
+++ linux-source-2.6.23-rc5/drivers/net/tg3.c 2007-09-27 16:29:44.904330381
-0400
@@ -6,13 +6,6 @@
* Copyright (C) 2004 Sun Microsystems Inc.
* Copyright (C) 2005-2007 Broadcom Corporation.
*
- * Firmware is:
- * Derived from proprietary unpublished source code,
- * Copyright (C) 2000-2003 Broadcom Corporation.
- *
- * Permission is hereby granted for the distribution of this firmware
- * data in hexadecimal or equivalent format, provided this copyright
- * notice is accompanying it.
*/
@@ -5131,123 +5124,6 @@ static int tg3_halt(struct tg3 *tp, int
return 0;
}
-#define TG3_FW_RELEASE_MAJOR 0x0
-#define TG3_FW_RELASE_MINOR0x0
-#define TG3_FW_RELEASE_FIX 0x0
-#define TG3_FW_START_ADDR 0x0800
-#define TG3_FW_TEXT_ADDR 0x0800
-#define TG3_FW_TEXT_LEN0x9c0
-#define TG3_FW_RODATA_ADDR 0x080009c0
-#define TG3_FW_RODATA_LEN 0x60
-#define TG3_FW_DATA_ADDR 0x08000a40
-#define TG3_FW_DATA_LEN0x20
-#define TG3_FW_SBSS_ADDR 0x08000a60
-#define TG3_FW_SBSS_LEN0xc
-#define TG3_FW_BSS_ADDR0x08000a70
-#define TG3_FW_BSS_LEN 0x10
-
-static const u32 tg3FwText[(TG3_FW_TEXT_LEN / sizeof(u32)) + 1] = {
- 0x, 0x1003, 0x, 0x000d, 0x000d, 0x3c1d0800,
- 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x2610, 0x0e18, 0x,
- 0x000d, 0x3c1d0800, 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100034,
- 0x0e00021c, 0x, 0x000d, 0x, 0x, 0x,
- 0x27bdffe0, 0x3c1cc000, 0xafbf0018, 0xaf80680c, 0x0e4c, 0x241b2105,
- 0x9785, 0x97870002, 0x9782002c, 0x9783002e, 0x3c040800, 0x248409c0,
- 0xafa00014, 0x00021400, 0x00621825, 0x00052c00, 0xafa30010, 0x8f860010,
- 0x00e52825, 0x0e60, 0x24070102, 0x3c02ac00, 0x34420100, 0x3c03ac01,
- 0x34630100, 0xaf820490, 0x3c02, 0xaf820494, 0xaf830498, 0xaf82049c,
- 0x24020001, 0xaf825ce0, 0x0e3f, 0xaf825d00, 0x0e000140, 0x,
- 0x8fbf0018, 0x03e8, 0x27bd0020, 0x2402, 0xaf825404, 0x8f835400,
- 0x34630400, 0xaf835400, 0xaf825404, 0x3c020800, 0x24420034, 0xaf82541c,
- 0x03e8, 0xaf805400, 0x, 0x, 0x3c020800, 0x34423000,
- 0x3c030800, 0x34633000, 0x3c040800, 0x348437ff, 0x3c010800, 0xac220a64,
- 0x24020040, 0x3c010800, 0xac220a68, 0x3c010800, 0xac200a60, 0xac60,
- 0x24630004, 0x0083102b, 0x5040fffd, 0xac60, 0x03e8, 0x,
- 0x00804821, 0x8faa0010, 0x3c020800, 0x8c420a60, 0x3c040800, 0x8c840a68,
- 0x8fab0014, 0x24430001, 0x0044102b, 0x3c010800, 0xac230a60, 0x1443,
- 0x4021, 0x3c010800, 0xac200a60, 0x3c020800, 0x8c420a60, 0x3c030800,
- 0x8c630a64, 0x9124, 0x00021140, 0x00431021, 0x00481021, 0x25080001,
- 0xa044, 0x29020008, 0x1440fff4, 0x25290001, 0x3c020800, 0x8c420a60,
- 0x3c030800, 0x8c630a64, 0x8f84680c, 0x00021140, 0x00431021, 0xac440008,
- 0xac45000c, 0xac460010, 0xac470014, 0xac4a0018, 0x03e8, 0xac4b001c,
- 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,
- 0x0208, 0x, 0x0a0001e3, 0x3c0a0001, 0x0a0001e3, 0x3c0a0002,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3, 0x,
- 0x0a0001e3, 0x3c0a0007, 0x0a0001e3, 0x3c0a0008, 0x0a0001e3, 0x3c0a0009,
- 0x0a0001e3, 0x, 0x0a0001e3, 0x, 0x0a0001e3,
Re: K8 Kernel Image
On 2007-09-02, Sascha Conradi [EMAIL PROTECTED] wrote: The AMD64 is a 64bit image!!! so you need the 64bit libs and by the way the old sempron without 64bit extension is allso K8 So this is not usable for some users with only 32bit cpu. All 32 bit semprons are K7, not K8. All 64 bit AMD CPUs are = K8. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
