Bug#247455: drivers/char/istallion.c:854: warning: too few arguments for format
It is probably nothing. Still, when compiling 2.6.7-2, I get: drivers/char/istallion.c: In function `istallion_module_exit': drivers/char/istallion.c:854: warning: too few arguments for format I believe that with earlier 2.6 sources there was a similar message, and maybe some other warning. -- If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas. -- George Bernard Shaw(sent by shaulk @ 013 . net . il)
Bug#257684: kernel-source-2.6.7: VIA AGP Chipsets not identified correctly
Package: kernel-source-2.6.7
Version: 2.6.7-2
Severity: normal
Tags: patch
There's a bug n the kernel that doesn't permit the correct
identification of the chipset used by the AGPGART driver if this is a
VIA chipset. (fo example KT600 identified as CLE266 )
This bug is solved in a newer version of AGPGART driver , an update that
solve this problem is included:
Bye
Marcello
agpgart-2004-06-17.diff :
diff -Nru a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig
--- a/drivers/char/agp/Kconfig 2004-06-17 00:04:01 +01:00
+++ b/drivers/char/agp/Kconfig 2004-06-17 00:04:01 +01:00
@@ -165,7 +165,7 @@
tristate Transmeta Efficeon support
depends on AGP X86 !X86_64
help
- This option fives you AGP support for the Transmeta Efficeon
+ This option gives you AGP support for the Transmeta Efficeon
series processors with integrated northbridges.
You should say Y here if you use XFree86 3.3.6 or 4.x and want
to
diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
--- a/drivers/char/agp/generic.c2004-06-17 00:04:01 +01:00
+++ b/drivers/char/agp/generic.c2004-06-17 00:04:01 +01:00
@@ -1,6 +1,6 @@
/*
* AGPGART driver.
- * Copyright (C) 2002-2003 Dave Jones.
+ * Copyright (C) 2002-2004 Dave Jones.
* Copyright (C) 1999 Jeff Hartmann.
* Copyright (C) 1999 Precision Insight, Inc.
* Copyright (C) 1999 Xi Graphics, Inc.
@@ -18,12 +18,12 @@
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS
* OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
- * JEFF HARTMANN, OR ANY OTHER CONTRIBUTORS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
+ * JEFF HARTMANN, OR ANY OTHER CONTRIBUTORS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
* OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*
- * TODO:
+ * TODO:
* - Allocate more than order 0 pages to avoid too much linear map
splitting.
*/
#include linux/config.h
@@ -37,7 +37,7 @@
#include linux/vmalloc.h
#include agp.h
-__u32 *agp_gatt_table;
+__u32 *agp_gatt_table;
int agp_memory_reserved;
/*
@@ -46,7 +46,7 @@
*/
EXPORT_SYMBOL_GPL(agp_memory_reserved);
-/*
+/*
* Generic routines for handling agp_memory structures -
* They use the basic page allocation routines to do the brunt of the
work.
*/
@@ -142,12 +142,12 @@
* agp_allocate_memory - allocate a group of pages of a certain
type.
*
* @page_count:size_t argument of the number of pages
- * @type: u32 argument of the type of memory to be allocated.
+ * @type: u32 argument of the type of memory to be allocated.
*
* Every agp bridge device will allow you to allocate
AGP_NORMAL_MEMORY which
* maps to physical ram. Any other type is device dependent.
*
- * It returns NULL whenever memory is unavailable.
+ * It returns NULL whenever memory is unavailable.
*/
struct agp_memory *agp_allocate_memory(size_t page_count, u32 type)
{
@@ -311,7 +311,7 @@
/**
* agp_bind_memory - Bind an agp_memory structure into the GATT.
- *
+ *
* @curr: agp_memory pointer
* @pg_start: an offset into the graphics aperture translation
table
*
@@ -347,9 +347,9 @@
/**
* agp_unbind_memory - Removes an agp_memory structure from the
GATT
- *
+ *
* @curr: agp_memory pointer to be removed from the GATT.
- *
+ *
* It returns -EINVAL if this piece of agp_memory is not currently
bound to
* the graphics aperture translation table or if the agp_memory pointer
== NULL
*/
@@ -404,12 +404,18 @@
*cmd = ~(AGPSTAT2_1X | AGPSTAT2_4X); /* 2X */
if (*cmd AGPSTAT2_1X)
- *cmd = ~(AGPSTAT2_2X | AGPSTAT2_4X); /* 1Xf */
+ *cmd = ~(AGPSTAT2_2X | AGPSTAT2_4X); /* 1X */
}
-
+/*
+ * mode = requested mode.
+ * cmd = PCI_AGP_STATUS from agp bridge.
+ * tmp = PCI_AGP_STATUS from graphic card.
+ */
static void agp_v3_parse_one(u32 *mode, u32 *cmd, u32 *tmp)
{
+ u32 origcmd=*cmd, origtmp=*tmp;
+
/* ARQSZ - Set the value to the maximum one.
* Don't allow the mode register to override values. */
*cmd = ((*cmd ~AGPSTAT_ARQSZ) |
@@ -452,17 +458,43 @@
*mode |= AGPSTAT3_4X;
}
- if (!((*cmd AGPSTAT3_8X) (*tmp AGPSTAT3_8X) (*mode
AGPSTAT3_8X)))
- *cmd = ~AGPSTAT3_8X;
+ if (*mode AGPSTAT3_8X) {
+ if (!(*cmd AGPSTAT3_8X)) {
+ *cmd = ~(AGPSTAT3_8X | AGPSTAT3_RSVD);
+ *cmd |= ~AGPSTAT3_4X;
+ printk (%s requested AGPx8 but bridge not
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
On Sat, 2004-07-03 at 22:43 +0200, Sven Luther wrote: I would suggest a solution as follows : 1) the XF86Config file is debconf managed : We query the database, inform the user with a low priority debconf question if it is set to psaux, and change it for him. This means a priority normal install will automatically make the change, so no user intervention is needed. Problem 1 : if you want to run 2.4 in parallel you are screwed, a solution would be to have the input/mice being the core pointer always, and the psaux sending core events. Keep in mind that using both /dev/psaux and /dev/input/mice at the same time with a 2.6 kernel will result in duplicate mouse events. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Fw: Kernel fault
Hi All I am sorry but I am not quite sure if this is the right list. I have been runing a debian system for about two years. There has never been any problems with stability. In the last month or so I keep getting bugs. Sometimes when transfering big files to the debian system via samba, other times without doing anything. The errors I get look like this: kernel BUG at page_alloc.c:235!invalid operand: CPU: 0EIP: 0010:[rmqueue+533/576] Not taintedEFLAGS: 00010202eax: 014c ebx: c130aaf0 ecx: 1000 edx: 0001038fesi: 0001efeb edi: c120 ebp: c02605b8 esp: daf41e5cds: 0018 es: 0018 ss: 0018Process sftp-server (pid: 1028, stackpage=daf41000)Stack: 1000 d04fc440 f38f 0296 c02605b8 c02605b8 c026078c 0001 c17feebc c0137e0b 00015e2a db4b7860 d04fc440 de291840 dd703260 c02605b8 c0260788 01d2 0001 db4b7914 00013d25 00013d44 Call Trace: [__alloc_pages+107/624] [page_cache_read+121/208] [af_packet:__insmod_af_packet_O/lib/modules/2.4.24-1-686/kernel/net/pa+-1284848/96] [generic_file_readahead+239/416] [do_generic_file_read+413/1120] [file_read_actor+0/224] [generic_file_read+183/432] [file_read_actor+0/224] [sys_read+163/320] [system_call+51/56]Code: 0f 0b eb 00 32 ca 23 c0 8b 43 18 a9 80 00 00 00 74 08 0f 0b After this the machine freezes and I can't do anything except turn it of. I am running kernel 2.4.24-1-686. Does anyone know what this is? Thanks! Kim
Re: Fw: Kernel fault
On Mon, Jul 05, 2004 at 10:29:34PM +0200, Kim wrote: eax: 014c ebx: c130aaf0 ecx: 1000 edx: 0001038f Single bit set. Does anyone know what this is? Bad RAM. Run memtest86 to confirm, but you've got all the classic symptoms of a broken DIMM. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain
Kernel fault
Hi All I am sorry but I am not quite sure if this is the right list. I have been runing a debian system for about two years. There has never been any problems with stability. In the last month or so I keep getting bugs. Sometimes when transfering big files to the debian system via samba, other times without doing anything. The errors I get look like this: kernel BUG at page_alloc.c:235!invalid operand: CPU: 0EIP: 0010:[rmqueue+533/576] Not taintedEFLAGS: 00010202eax: 014c ebx: c130aaf0 ecx: 1000 edx: 0001038fesi: 0001efeb edi: c120 ebp: c02605b8 esp: daf41e5cds: 0018 es: 0018 ss: 0018Process sftp-server (pid: 1028, stackpage=daf41000)Stack: 1000 d04fc440 f38f 0296 c02605b8 c02605b8 c026078c 0001 c17feebc c0137e0b 00015e2a db4b7860 d04fc440 de291840 dd703260 c02605b8 c0260788 01d2 0001 db4b7914 00013d25 00013d44 Call Trace: [__alloc_pages+107/624] [page_cache_read+121/208] [af_packet:__insmod_af_packet_O/lib/modules/2.4.24-1-686/kernel/net/pa+-1284848/96] [generic_file_readahead+239/416] [do_generic_file_read+413/1120] [file_read_actor+0/224] [generic_file_read+183/432] [file_read_actor+0/224] [sys_read+163/320] [system_call+51/56]Code: 0f 0b eb 00 32 ca 23 c0 8b 43 18 a9 80 00 00 00 74 08 0f 0b After this the machine freezes and I can't do anything except turn it of. I am running kernel 2.4.24-1-686. Does anyone know what this is? Thanks! Kim
Bug#257738: kernel-headers basically useless
Package: kernel Severity: normal To my understanding, kernel-headers are to be used in compiling kernel modules. However, quite a few modules require $KERNELSOURCE/drivers, others try to execute `make modules` in the KSRC directory, and yet others only work with make-kpkg, which requires the kernel source. Therefore, it seems to me that the kernel-headers packages have no use (at least in 2.6). The following module-source packages cannot be built with the headers only: drm-mach64, bcm4400, bcm5700, lirc, pcmcia, freeswan, openswan, arla, openafs. In all cases, I tried: ./debian/rules KSRC=/usr/src/kernel-headers-X.Y.ZZ binary and ./debian/rules KSRC=/usr/src/kernel-headers-X.Y.ZZ modules-binary Either I am doing something wrong, or the kernel-headers packages are really not needed anymore. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (600, 'testing'), (98, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Fw: Kernel fault
Dear Matthew Thank you very much! You where right, I had a fault in one of the memory blocks. Kim - Original Message - From: Matthew Wilcox [EMAIL PROTECTED] To: Kim [EMAIL PROTECTED] Cc: debian-kernel@lists.debian.org Sent: Monday, July 05, 2004 10:38 PM Subject: Re: Fw: Kernel fault On Mon, Jul 05, 2004 at 10:29:34PM +0200, Kim wrote: eax: 014c ebx: c130aaf0 ecx: 1000 edx: 0001038f Single bit set. Does anyone know what this is? Bad RAM. Run memtest86 to confirm, but you've got all the classic symptoms of a broken DIMM. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain
Bug#257738: kernel-headers basically useless
On Mon, Jul 05, 2004 at 07:57:01PM +0200, martin f krafft wrote: Package: kernel Severity: normal To my understanding, kernel-headers are to be used in compiling kernel modules. However, quite a few modules require $KERNELSOURCE/drivers, others try to execute `make modules` in the KSRC directory, and yet others only work with make-kpkg, which requires the kernel source. Please fix the drivers instead. Drivers aren't supposed to poke into random kernel sources.
Bug#257738: kernel-headers basically useless
#include hallo.h * martin f krafft [Mon, Jul 05 2004, 07:57:01PM]: To my understanding, kernel-headers are to be used in compiling kernel modules. However, quite a few modules require $KERNELSOURCE/drivers, If they don't describe it in the manual, file bugs. others try to execute `make modules` This works with kernel-headers-2.6...! And for versions below this method be used because whatsoever. in the KSRC directory Not just in the KSRC directory, they parametrize the call. This is a valid behaviour and recent kernel-package packages include enough files to have working build infrastructure. and yet others only work with make-kpkg, which requires the kernel source. Ehm, what do you mean? The module-source _are_ to be used with make-kpkg or compatible build method (eg. running debian/rules with the needed arguments and environment, or using the module-assistant utility). Therefore, it seems to me that the kernel-headers packages have no use (at least in 2.6). The following module-source packages cannot be built with the headers only: drm-mach64, bcm4400, bcm5700, lirc, pcmcia, freeswan, openswan, arla, openafs. side noteThis number of packages is very low (almost ridiculous) for a good statistic. / I just tried to build the few source packages installed here with kernel-headers-2.6.6-2-686 (using module-assistant alli -k ...) and most worked: cloop, nvidia, sl-modem, lufs, cdfs, shfs, bcm4400, bcm5700, lufs, ipw2100, ppscsi Some have failed: pcmcia (internal bug, needless requirement of modversions.h) arla (weird hocus pocus with mirroring the kernel build system, broken) loop-aes (using arbitrary build system based on kernel source, known to need the complete source) In all cases, I tried: Ehm, what about trying to read the docs or make-kpkg source before reporting bugs? ./debian/rules KSRC=/usr/src/kernel-headers-X.Y.ZZ modules-binary This is _not_ the rule that make-kpkg calls! Some people think that it is a must for module-source packages but it is AFAICS just an invention of the dh-make author to unify some commands (but I must admit, I have partially reused its concept in module-assistant include files ;). Either I am doing something wrong You are. Please read the source of a good module-source package (eg. ALSA) or one control script and/or makefile includes from module-assistant. OTOH, you are a DD and module-source maintainer, do I really need to tell you to RTFM? Regards, Eduard. signature.asc Description: Digital signature
Bug#257763: segmentation fault on loading speedstep_centrino
package: kernel-image-2.6.6-1-686 version: 2.6.6-1 package: kernel-image-2.6.6-2-686 version: 2.6.6-2 package: kernel-image-2.6.7-1-686 version: 2.6.7-1 hi, when i try to load the module speedstep_centrino it fails with a segmentation fault. the kernel versions prior and including kernel-image-2.6.5-1-686 works perfectly. i am using debian sarge on a asus s5200n with pentium m 1,4ghz. output from dmesg and /var/log/messages while loading speedstep_centrino is below. but i don't see in there something wrong. thanx, jens mueller igh level) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Built 1 zonelists Kernel command line: root=/dev/hda3 ro Initializing CPU#0 PID hash table entries: 1024 (order 10: 8192 bytes) Detected 1400.288 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Memory: 243192k/253184k available (1515k kernel code, 9264k reserved, 662k data, 148k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 2777.08 BogoMIPS Security Scaffold v1.0.0 initialized Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: a7e9fbbf CPU: After vendor identify, caps: a7e9fbbf CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 1024K CPU: After all inits, caps: a7e9fbbf 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel(R) Pentium(R) M processor 1400MHz stepping 05 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 1-0, 1-16, 1-17, 1-18, 1-19, 1-20, 1-21, 1-22, 1-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=-1 Using local APIC timer interrupts. calibrating APIC timer ... . CPU clock speed is 1399.0759 MHz. . host bus clock speed is 99.0982 MHz. checking if image is initramfs...it isn't (ungzip failed); looks like an initrd Freeing initrd memory: 4684k freed NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040326 ACPI-0077: *** Warning: Invalid FADT value PM_TM_LEN=3 at offset 5B FADT=cf29b278 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] ACPI: Embedded Controller [EC0] (gpe 28) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 11 12) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 12) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *7 12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 *4 5 6 7 12) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 12) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 12) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 12) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 12) ACPI: Power Resource [GFAN] (off) Linux Plug and Play Support v0.97 (c) Adam Belay PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00f3260 PnPBIOS: PnP BIOS version 1.0, entry 0xf:0x3e5a, dseg 0xf pnp: 00:0a: ioport range 0x4d0-0x4d1 has been reserved pnp: 00:0a: ioport range 0xcf8-0xcff could not be reserved PnPBIOS: 12 nodes reported by PnP BIOS; 12 recorded by driver 00:00:02[A] - 1-16 - IRQ 16 level low 00:00:1f[A] - 1-18 - IRQ 18 level low 00:00:1f[B] - 1-17 - IRQ 17 level low 00:00:1d[B] - 1-19 - IRQ 19 level low 00:00:1d[D] - 1-23 - IRQ 23 level low number of MP IRQ sources: 15. number of IO-APIC #1 registers: 24. testing the IO APIC... IO APIC #1.. register #00: 0100 ...: physical APIC id: 01 ...: Delivery Type: 0 ...: LTS : 0 register #01: 00178020 ... : max redirection entries: 0017 ... : PRQ implemented: 1 ... : IO APIC version: 0020 register #02: ... : arbitration: 00 register #03: 0001 ... : Boot DT: 1 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 001 01 000 0 01139 02 001 01 000 0 01131 03 001 01 000 0 01141 04 001 01 000 0 01149 05 001 01 000 0 01151 06 001 01 0
Bug#257738: kernel-headers basically useless
On Mon, 05 Jul 2004 19:57:01 +0200, martin f krafft wrote: [...] Either I am doing something wrong, or the kernel-headers packages are really not needed anymore. They most certainly are needed. Modules should be unpacked in /usr/src/modules, and then one can do a `make-kpkg --append_to_version=-1-k7 modules_image` to create kernel modules that are compatible w/ the running kernel. See qc-usb-source for an example of a kernel module that compiles fine against debian kernel headers. The modules you listed should be fixed. Please assign bugs to them as appropriate.
Bug#257790: kernel-source-2.6.7: arch/i386/power/built-in.o fails to link during compile
Package: kernel-source-2.6.7 Version: 2.6.7-2 Severity: important During compilation (with make-kpkg) I got this error: GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 arch/i386/power/built-in.o(.text+0x253): In function `do_magic': : undefined reference to `swsusp_pg_dir' make[1]: *** [.tmp_vmlinux1] Error 1 make[1]: Leaving directory `/usr/src/kernel-source-2.6.7' make: *** [stamp-build] Error 2 I don't know if I lak some required packages, but with kernel-source-2.6.6 all went well, and I used oldconfig to generate .config. The make-kpkg line was: # make-kpkg --revision 01 --config oldconfig --append-to-version -caino kernel_image modules_image. If you want, I can submit also my .config. Thanks. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.6-caino Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 Versions of packages kernel-source-2.6.7 depends on: ii binutils 2.14.90.0.7-8 The GNU assembler, linker and bina ii bzip2 1.0.2-1 A high-quality block-sorting file ii coreutils [fileutils] 5.0.91-2 The GNU core utilities ii fileutils 5.0.91-2 The GNU file management utilities -- no debconf information
Re: Bug#257738: kernel-headers basically useless
On Mon, 5 Jul 2004 19:57:01 +0200, martin f krafft [EMAIL PROTECTED] said: Package: kernel Severity: normal To my understanding, kernel-headers are to be used in compiling kernel modules. However, quite a few modules require $KERNELSOURCE/drivers, others try to execute `make modules` in the KSRC directory, and yet others only work with make-kpkg, which requires the kernel source. You can build kere modules using kernel-package without having the sources unpacked (look for IN_KERNEL_HEADERS in /usr/share/kernel-package/rules) -- if this is not so, I would appreciate being told what is going wrong. Either I am doing something wrong, or the kernel-headers packages are really not needed anymore. However, I must confess I have not tested with the new 2.6 build mechanism. manoj -- malpractice, n.: The reason surgeons wear masks. Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#256374: Installation hangs on Compaq Presario 1220 while loading module 'ide-cd' during hardware detection for the CD-ROM drive (beta4, i386, linux26)
Per Olofsson wrote: On Sat, Jul 03, 2004 at 08:58 -0300, Robin Blondon wrote: Under 2.6, when I have i82365 and orinoco_cs in /etc/modules, yenta_socket is not loaded and it doesn't look like it tries to load it (I checked boot messages, dmesg, and syslog) but it does attempt to load memory_cs. When I do not have i82365 and orinoco_cs in /etc/modules, it does load it. But can you check with lsmod after pcmcia has started? And what does cardctl ident say? Under 2.6, when I have i82365 and orinoco_cs in /etc/modules, lsmod shows that yenta_socket is not loaded. cardctl ident says: Socket 0: cs: unable to map card memory! cs: unable to map card memory! no product info available cs: unable to map card memory! cs: unable to map card memory! cs: unable to map card memory! cs: unable to map card memory! When I kill cardmgr and run cardctl ident again, it gives the same results. When I do not have i82365 and orinoco_cs in /etc/modules, lsmod shows that yenta_socket is loaded. cardctl ident says: open_sock(): No such device Also, if I try to run cardmgr, cardmgr says: cardmgr[1118]: no sockets found! - Robin
Bug#257783: Weird oopses with 2.6.6
Package: kernel-image-2.6.6-1-686-smp Version: 2.6.6-1-686-smp Severity: normal I run Debian Sarge with 2.6.6 on a 3GHz P4. The method used was apt-get install and all dependencies were automatically resolved. The kernel boots fine, but the session only lasts from 1 to 48 hours. After that, weird things happen. Most obvious thing that happens is that KDE crashes. Its KPanel is gone and I have to log out to reinitialize it. Sometimes this doesn't even help and I have to completely reboot the machine in order to fix the issue. After looking in /var/log/messages I discovered that weird kernel oopses are logged there. See attached file. My system is a 3GHz P4 with HT, an ASUS P4P800 Deluxe board and 1G RAM. I've attached a bootlog in a separate file. Note: It's possible that this bug is related to an earlier one, which was caused by weird ASUS BIOS stuff. See Bug#226996. Please advise on what more information I can provide. Regards, Jeroen van Disseldorp Jul 5 04:51:19 newton kernel: printing eip: Jul 5 04:51:19 newton kernel: f883358e Jul 5 04:51:19 newton kernel: Oops: 0002 [#2] Jul 5 04:51:19 newton kernel: PREEMPT SMP Jul 5 04:51:19 newton kernel: CPU:0 Jul 5 04:51:19 newton kernel: EIP:0060:[__crc___getblk+2047739/2951148] Tainted: P Jul 5 04:51:19 newton kernel: EFLAGS: 00210202 (2.6.6-1-686-smp) Jul 5 04:51:19 newton kernel: EIP is at unix_stream_sendmsg+0x1e/0x420 [unix] Jul 5 04:51:19 newton kernel: eax: f634ff3d ebx: f2454080 ecx: f634ff0c edx: f0ef7920 Jul 5 04:51:19 newton kernel: esi: f2454080 edi: f634fecc ebp: 03e0 esp: f634fe40 Jul 5 04:51:19 newton kernel: ds: 007b es: 007b ss: 0068 Jul 5 04:51:19 newton kernel: Process kdeinit (pid: 6310, threadinfo=f634e000 task=ef6a2eb0) Jul 5 04:51:19 newton kernel: Stack: f0ef7920 ffa1 0001 0020 f0ef7920 f634ff0c 0abf Jul 5 04:51:19 newton kernel: c0142015 c02d1080 f2454080 Jul 5 04:51:19 newton kernel:0040 f2454080 f634fecc 03e0 c021fb0d f634fecc f2454080 f634ff2c Jul 5 04:51:19 newton kernel: Call Trace: Jul 5 04:51:19 newton kernel: [__alloc_pages+165/800] __alloc_pages+0xa5/0x320 Jul 5 04:51:19 newton kernel: [sock_aio_write+189/224] sock_aio_write+0xbd/0xe0 Jul 5 04:51:19 newton kernel: [do_sync_write+137/192] do_sync_write+0x89/0xc0 Jul 5 04:51:19 newton kernel: [do_select+457/784] do_select+0x1c9/0x310 Jul 5 04:51:19 newton kernel: [vfs_write+289/352] vfs_write+0x121/0x160 Jul 5 04:51:19 newton kernel: [sys_write+66/112] sys_write+0x42/0x70 Jul 5 04:51:19 newton kernel: [syscall_call+7/11] syscall_call+0x7/0xb Jul 5 04:51:19 newton kernel: Jul 5 04:51:19 newton kernel: Code: d2 89 54 24 10 8b 70 18 85 f6 75 0d 8b 4c 24 18 8d 44 24 20 Jul 6 00:03:38 newton kernel: printing eip: Jul 6 00:03:38 newton kernel: f883358e Jul 6 00:03:38 newton kernel: Oops: 0002 [#1] Jul 6 00:03:38 newton kernel: PREEMPT SMP Jul 6 00:03:38 newton kernel: CPU:0 Jul 6 00:03:38 newton kernel: EIP:0060:[__crc___getblk+2047739/2951148] Tainted: P Jul 6 00:03:38 newton kernel: EFLAGS: 00210202 (2.6.6-1-686-smp) Jul 6 00:03:38 newton kernel: EIP is at unix_stream_sendmsg+0x1e/0x420 [unix] Jul 6 00:03:38 newton kernel: eax: f5207f3d ebx: f53b7940 ecx: f5207f0c edx: f53cbb00 Jul 6 00:03:38 newton kernel: esi: f53b7940 edi: f5207ecc ebp: 0008 esp: f5207e40 Jul 6 00:03:38 newton kernel: ds: 007b es: 007b ss: 0068 Jul 6 00:03:38 newton kernel: Process kdeinit (pid: 3061, threadinfo=f5206000 task=f6a37200) Jul 6 00:03:38 newton kernel: Stack: f53cbb00 f7868040 f693feb4 c0291752 f5207eb4 00200082 f5207f0c c13ddee0 Jul 6 00:03:38 newton kernel: 0001 f6b0a920 0001 c0142015 c02d1080 00d0 Jul 6 00:03:38 newton kernel:0040 f53b7940 f5207ecc 0008 c021fb0d f5207ecc f53b7940 f5207f2c Jul 6 00:03:38 newton kernel: Call Trace: Jul 6 00:03:38 newton kernel: [schedule+882/1808] 1Unable to handle kernel paging request at virtual address 79cb9614 Jul 6 00:03:38 newton kernel: printing eip: Jul 6 00:03:38 newton kernel: f883358e Jul 6 00:03:38 newton kernel: schedule+0x372/0x710 Jul 6 00:03:38 newton kernel: [__alloc_pages+165/800] __alloc_pages+0xa5/0x320 Jul 6 00:03:38 newton kernel: [sock_aio_write+189/224] sock_aio_write+0xbd/0xe0 Jul 6 00:03:38 newton kernel: [do_sync_write+137/192] do_sync_write+0x89/0xc0 Jul 6 00:03:38 newton kernel: [do_select+457/784] do_select+0x1c9/0x310 Jul 6 00:03:38 newton kernel: [update_wall_time+22/64] update_wall_time+0x16/0x40 Jul 6 00:03:38 newton kernel: [do_timer+192/208] do_timer+0xc0/0xd0 Jul 6 00:03:38 newton kernel: [timer_interrupt+116/368] timer_interrupt+0x74/0x170 Jul 6 00:03:38 newton kernel: [vfs_write+289/352] vfs_write+0x121/0x160 Jul 6 00:03:38 newton kernel: [sys_write+66/112] sys_write+0x42/0x70 Jul 6 00:03:38
