re: bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
forwarding to lkml, as no response on netdev list so far. maybe someone has a clue how to properly fix this timing issue. the remaining question is about how to correctly replace readl() with inl() to make it compile cleanly or how eeprom_delay() is being done correctly. inl() seems to be slower to complete which seems to make the driver work, but it seems it needs an I/O port as param but not an memory-adress. sorry, i`m not good at programming, but now as the problem is "basically" fixed there are just some tiny bits missing for a proper fix. i´m unsure if typecasting ee_addr is the right thing to do (i think it`s not) and if a patch with such typecast would have any chance for being accepted. hi, as i`m doing a little project with this older devices, i have come across this issue again and had some fun to dig deeper into it. it`s a little bit academic, as i can do ifconfig eth0 hw ether. as a workaround, but it sucks to hack that into startup scripts and i also have seen udev not playing nicely with it. apparently the problem is being caused by a timing issue in the natsemi driver. i added some debug printk`s in natsemi.c -> eeprom_read() after each occurrence of eeprom_delay(ee_addr); , and the problem went away. there is a hint about timing sensitivity in the code: /* Delay between EEPROM clock transitions. No extra delay is needed with 33Mhz PCI, but future 66Mhz access may need a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that made udelay() unreliable. The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is deprecated. */ looking at the source of natsemi-diag.c made me wonder why that utility is using #define eeprom_delay(ee_addr) inl(ee_addr) instead of #define eeprom_delay(ee_addr) readl(ee_addr) and apparently, that also fixes the problem (but gives a compile warning): drivers/net/ethernet/natsemi/natsemi.c: In function âeeprom_readâ: drivers/net/ethernet/natsemi/natsemi.c:1019:3: warning: passing argument 1 of âinlâ makes integer from pointer without a cast [enabled by default] In file included from include/linux/io.h:22:0, from include/linux/pci.h:54, from drivers/net/ethernet/natsemi/natsemi.c:38: looking at a more recent version of natsemi-diag.c , i even found this one: ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c /* Delay between EEPROM clock transitions. This flushes the write buffer to prevent quick double-writes. */ #define eeprom_delay(ee_addr) inl(ee_addr); inl(ee_addr) The question is how to make a proper fix, as i don`t know what to pass to inl() , as it seems it should not get an mmapped adress but an i/o port instead !? "The in*() functions return data read from the specified I/O port" "The read*() functions read data from device memory previously mapped by map_memory()" regards roland ps: CC driver maintainer from Kernel Maintainers file. Roland Kletzing | 17 Dec 13:38 2012 bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load Hello, i recently played with my older evo t20/wyse 3235le thin clients and flashed a linux kernel into those, apparently there seems an issue with the natsemi driver. after driver load (natsemi.ko) eth0 has no valid mac adress, dmesg and ifconfig shows just zero`s: 00:00:00:00:00:00. despite that , the nic is working fine for me (in this test setup i set the mac manually: ifconfig eth0 hw ether de:ad:be:ef:be:ef ) apparently, the driver fails to read the proper mac from the eeprom, as "natsemi-diag -ee" (from nictools-pci in debian squeeze) shows, that there is a valid "Ethernet MAC Station Address" stored inside the eeprom. (see below) looks like a driver bug !? does anybody have a clue what`s going wrong here? regards roland #lspci 00:00.0 Host bridge: Cyrix Corporation PCI Master 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30) 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua] 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua] 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua] 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua] 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev 06) #dmesg |egrep "natsemi|eth" natsemi dp8381x driver, version 2.1, Sept 11, 2006 natsemi :00:0f.0: setting latency timer to 64 natsemi eth0: NatSemi DP8381[56] at 0x401 (:00:0f.0), 00:00:00:00:00:00, IRQ 10, port TP. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. #natsemi-diag -aa natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a NatSemi DP83815 adapter at 0xf800. Natsemi 83815 series with station address
re: bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
forwarding to lkml, as no response on netdev list so far. maybe someone has a clue how to properly fix this timing issue. the remaining question is about how to correctly replace readl() with inl() to make it compile cleanly or how eeprom_delay() is being done correctly. inl() seems to be slower to complete which seems to make the driver work, but it seems it needs an I/O port as param but not an memory-adress. sorry, i`m not good at programming, but now as the problem is basically fixed there are just some tiny bits missing for a proper fix. i´m unsure if typecasting ee_addr is the right thing to do (i think it`s not) and if a patch with such typecast would have any chance for being accepted. hi, as i`m doing a little project with this older devices, i have come across this issue again and had some fun to dig deeper into it. it`s a little bit academic, as i can do ifconfig eth0 hw ether. as a workaround, but it sucks to hack that into startup scripts and i also have seen udev not playing nicely with it. apparently the problem is being caused by a timing issue in the natsemi driver. i added some debug printk`s in natsemi.c - eeprom_read() after each occurrence of eeprom_delay(ee_addr); , and the problem went away. there is a hint about timing sensitivity in the code: /* Delay between EEPROM clock transitions. No extra delay is needed with 33Mhz PCI, but future 66Mhz access may need a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that made udelay() unreliable. The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is deprecated. */ looking at the source of natsemi-diag.c made me wonder why that utility is using #define eeprom_delay(ee_addr) inl(ee_addr) instead of #define eeprom_delay(ee_addr) readl(ee_addr) and apparently, that also fixes the problem (but gives a compile warning): drivers/net/ethernet/natsemi/natsemi.c: In function âeeprom_readâ: drivers/net/ethernet/natsemi/natsemi.c:1019:3: warning: passing argument 1 of âinlâ makes integer from pointer without a cast [enabled by default] In file included from include/linux/io.h:22:0, from include/linux/pci.h:54, from drivers/net/ethernet/natsemi/natsemi.c:38: looking at a more recent version of natsemi-diag.c , i even found this one: ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c /* Delay between EEPROM clock transitions. This flushes the write buffer to prevent quick double-writes. */ #define eeprom_delay(ee_addr) inl(ee_addr); inl(ee_addr) The question is how to make a proper fix, as i don`t know what to pass to inl() , as it seems it should not get an mmapped adress but an i/o port instead !? The in*() functions return data read from the specified I/O port The read*() functions read data from device memory previously mapped by map_memory() regards roland ps: CC driver maintainer from Kernel Maintainers file. Roland Kletzing | 17 Dec 13:38 2012 bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load Hello, i recently played with my older evo t20/wyse 3235le thin clients and flashed a linux kernel into those, apparently there seems an issue with the natsemi driver. after driver load (natsemi.ko) eth0 has no valid mac adress, dmesg and ifconfig shows just zero`s: 00:00:00:00:00:00. despite that , the nic is working fine for me (in this test setup i set the mac manually: ifconfig eth0 hw ether de:ad:be:ef:be:ef ) apparently, the driver fails to read the proper mac from the eeprom, as natsemi-diag -ee (from nictools-pci in debian squeeze) shows, that there is a valid Ethernet MAC Station Address stored inside the eeprom. (see below) looks like a driver bug !? does anybody have a clue what`s going wrong here? regards roland #lspci 00:00.0 Host bridge: Cyrix Corporation PCI Master 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30) 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua] 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua] 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua] 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua] 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev 06) #dmesg |egrep natsemi|eth natsemi dp8381x driver, version 2.1, Sept 11, 2006 natsemi :00:0f.0: setting latency timer to 64 natsemi eth0: NatSemi DP8381[56] at 0x401 (:00:0f.0), 00:00:00:00:00:00, IRQ 10, port TP. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. #natsemi-diag -aa natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker at scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a NatSemi DP83815 adapter at 0xf800. Natsemi 83815 series with station address de:ad:be:ef:be:ef
Re: dmesg spam: "PnPBIOS: pnp_dock_thread: unexpected status 0x5 flooding"
> Change the default to
>
> default:
> pnpbios_print_status("pnp_dock. etc)
> printk(KERN_ERR "PnPBIOS: Disabling dock monitoring\n");
> complete_and_exit(_sem, 0);
>
> that should produce you one error message, a warning that dock monitoring
> is being disabled and then it should stfu.
>
> If you can let us know if that does the trick then I can push it upstream.
works perfectly - thanks very much !
[9.712027] Switching to clocksource tsc
[9.903305] udevd[42]: starting version 175
[ 10.637309] natsemi dp8381x driver, version 2.1, Sept 11, 2006
[ 10.637345] originally by Donald Becker
[ 10.637371] 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
[ 10.700287] natsemi :00:0f.0: setting latency timer to 64
[ 10.880548] natsemi eth0: NatSemi DP8381[56] at 0x801 (:00:0f.0),
00:00:00:00:00:00, IRQ 10, port TP.
[ 11.025143] PnPBIOS: pnp_dock_thread: unexpected status 0x5
>[ 11.026800] PnPBIOS: Disabling dock monitoring
[ 11.518269] SCSI subsystem initialized
[ 11.550857] usbcore: registered new interface driver usbfs
> I've not seen other reports of pnp_dock_thread errors with a real dock.
> The only reports at all are a couple of old ones in google that seem to
> be similar and a Debian bug (294652) which appears to be your bug so I'd
indeed - seems a rather weird/rare/old one.
glad that you fixed it, though. thanks again!
roland
> Gesendet: Montag, 10. November 2014 um 14:54 Uhr
> Von: "One Thousand Gnomes"
> An: devz...@web.de
> Cc: linux-kernel@vger.kernel.org, rafael.j.wyso...@intel.com
> Betreff: Re: dmesg spam: "PnPBIOS: pnp_dock_thread: unexpected status 0x5
> flooding"
>
> On Fri, 7 Nov 2014 00:54:31 +0100
> devz...@web.de wrote:
>
> > Hi,
> >
> > on an ancient GX1 Geode embedded board (Evo T20/Wyse wt3235le Thin Client,
> > which are cheap (<$10) and low power x86 embeded platform) , dmesg is
> > getting constantly spammed with "PnPBIOS: pnp_dock_thread: unexpected
> > status 0x5" during and after boot.
> >
> > Any ideas what this means and how to stop that?
> >
> > It seems it comes from drivers/pnp/pnpbios/bioscalls.c ->
> > pnpbios_print_status()
> >
> > Tried adding pnpbios=off, but with that the system does not boot anymore.
> >
> > Being curious, why a non-existing docking-station is being "polled at
> > regular intervals" (i.e. every 2 seconds - see drivers/pnp/pnpbios/core.c )
>
> We poll for a dock, and if the BIOS reports that the function is not
> supported we then exit the thread.
>
> >
> > >From
> > >http://books.google.de/books?id=ibLa4I5EnC4C=PA231=PA231=pnp+docking+bios=bl=ekCFm34U_B=9Z9L55IAL7_3NtuM10jT3serncM=de=X=mAZcVILnJsviO-r5gNgI=0CCsQ6AEwAQ#v=onepage=pnp%20docking%20bios=false
> > > i read: "Function 05h - Get Docking Status Information at page 251"
>
> The spec is available at:
>
> http://download.intel.com/support/motherboards/desktop/sb/pnpbiosspecificationv10a.pdf
>
> > it seems this is being the result of a "docking event" ? Does this mean,
> > my system is erroneusly generating such docking events, even if there is no
> > docking station at all?
>
> Your BIOS appears to be making strange replies. Any error ought to have
> the top bit set, so its reporting a nonsense value for some reason.
>
> I've not seen other reports of pnp_dock_thread errors with a real dock.
> The only reports at all are a couple of old ones in google that seem to
> be similar and a Debian bug (294652) which appears to be your bug so I'd
> suggest testing the following
>
>
> Change the default to
>
> default:
> pnpbios_print_status("pnp_dock. etc)
> printk(KERN_ERR "PnPBIOS: Disabling dock monitoring\n");
> complete_and_exit(_sem, 0);
>
> that should produce you one error message, a warning that dock monitoring
> is being disabled and then it should stfu.
>
> If you can let us know if that does the trick then I can push it upstream.
>
> Alan
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg spam: PnPBIOS: pnp_dock_thread: unexpected status 0x5 flooding
Change the default to default: pnpbios_print_status(pnp_dock. etc) printk(KERN_ERR PnPBIOS: Disabling dock monitoring\n); complete_and_exit(unload_sem, 0); that should produce you one error message, a warning that dock monitoring is being disabled and then it should stfu. If you can let us know if that does the trick then I can push it upstream. works perfectly - thanks very much ! [9.712027] Switching to clocksource tsc [9.903305] udevd[42]: starting version 175 [ 10.637309] natsemi dp8381x driver, version 2.1, Sept 11, 2006 [ 10.637345] originally by Donald Becker bec...@scyld.com [ 10.637371] 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder [ 10.700287] natsemi :00:0f.0: setting latency timer to 64 [ 10.880548] natsemi eth0: NatSemi DP8381[56] at 0x801 (:00:0f.0), 00:00:00:00:00:00, IRQ 10, port TP. [ 11.025143] PnPBIOS: pnp_dock_thread: unexpected status 0x5 [ 11.026800] PnPBIOS: Disabling dock monitoring [ 11.518269] SCSI subsystem initialized [ 11.550857] usbcore: registered new interface driver usbfs I've not seen other reports of pnp_dock_thread errors with a real dock. The only reports at all are a couple of old ones in google that seem to be similar and a Debian bug (294652) which appears to be your bug so I'd indeed - seems a rather weird/rare/old one. glad that you fixed it, though. thanks again! roland Gesendet: Montag, 10. November 2014 um 14:54 Uhr Von: One Thousand Gnomes gno...@lxorguk.ukuu.org.uk An: devz...@web.de Cc: linux-kernel@vger.kernel.org, rafael.j.wyso...@intel.com Betreff: Re: dmesg spam: PnPBIOS: pnp_dock_thread: unexpected status 0x5 flooding On Fri, 7 Nov 2014 00:54:31 +0100 devz...@web.de wrote: Hi, on an ancient GX1 Geode embedded board (Evo T20/Wyse wt3235le Thin Client, which are cheap ($10) and low power x86 embeded platform) , dmesg is getting constantly spammed with PnPBIOS: pnp_dock_thread: unexpected status 0x5 during and after boot. Any ideas what this means and how to stop that? It seems it comes from drivers/pnp/pnpbios/bioscalls.c - pnpbios_print_status() Tried adding pnpbios=off, but with that the system does not boot anymore. Being curious, why a non-existing docking-station is being polled at regular intervals (i.e. every 2 seconds - see drivers/pnp/pnpbios/core.c ) We poll for a dock, and if the BIOS reports that the function is not supported we then exit the thread. From http://books.google.de/books?id=ibLa4I5EnC4Cpg=PA231lpg=PA231dq=pnp+docking+biossource=blots=ekCFm34U_Bsig=9Z9L55IAL7_3NtuM10jT3serncMhl=desa=Xei=mAZcVILnJsviO-r5gNgIved=0CCsQ6AEwAQ#v=onepageq=pnp%20docking%20biosf=false i read: Function 05h - Get Docking Status Information at page 251 The spec is available at: http://download.intel.com/support/motherboards/desktop/sb/pnpbiosspecificationv10a.pdf it seems this is being the result of a docking event ? Does this mean, my system is erroneusly generating such docking events, even if there is no docking station at all? Your BIOS appears to be making strange replies. Any error ought to have the top bit set, so its reporting a nonsense value for some reason. I've not seen other reports of pnp_dock_thread errors with a real dock. The only reports at all are a couple of old ones in google that seem to be similar and a Debian bug (294652) which appears to be your bug so I'd suggest testing the following Change the default to default: pnpbios_print_status(pnp_dock. etc) printk(KERN_ERR PnPBIOS: Disabling dock monitoring\n); complete_and_exit(unload_sem, 0); that should produce you one error message, a warning that dock monitoring is being disabled and then it should stfu. If you can let us know if that does the trick then I can push it upstream. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dmesg spam: "PnPBIOS: pnp_dock_thread: unexpected status 0x5 flooding"
Hi, on an ancient GX1 Geode embedded board (Evo T20/Wyse wt3235le Thin Client, which are cheap (<$10) and low power x86 embeded platform) , dmesg is getting constantly spammed with "PnPBIOS: pnp_dock_thread: unexpected status 0x5" during and after boot. Any ideas what this means and how to stop that? It seems it comes from drivers/pnp/pnpbios/bioscalls.c -> pnpbios_print_status() Tried adding pnpbios=off, but with that the system does not boot anymore. Being curious, why a non-existing docking-station is being "polled at regular intervals" (i.e. every 2 seconds - see drivers/pnp/pnpbios/core.c ) >From >http://books.google.de/books?id=ibLa4I5EnC4C=PA231=PA231=pnp+docking+bios=bl=ekCFm34U_B=9Z9L55IAL7_3NtuM10jT3serncM=de=X=mAZcVILnJsviO-r5gNgI=0CCsQ6AEwAQ#v=onepage=pnp%20docking%20bios=false > i read: "Function 05h - Get Docking Status Information at page 251" it seems this is being the result of a "docking event" ? Does this mean, my system is erroneusly generating such docking events, even if there is no docking station at all? regards roland ps: i`m booting via plopKexec Bootloader ( http://www.plop.at/de/plopkexec.html ) , as i can put kernel+rootfs on external usb and don`t need to reflash the device, which is complicated task. pps: some few old pointers from other people reporting it: https://lists.debian.org/debian-kernel/2005/02/msg00238.html http://sourceforge.net/p/open-evot20/mailman/message/20065770/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dmesg spam: PnPBIOS: pnp_dock_thread: unexpected status 0x5 flooding
Hi, on an ancient GX1 Geode embedded board (Evo T20/Wyse wt3235le Thin Client, which are cheap ($10) and low power x86 embeded platform) , dmesg is getting constantly spammed with PnPBIOS: pnp_dock_thread: unexpected status 0x5 during and after boot. Any ideas what this means and how to stop that? It seems it comes from drivers/pnp/pnpbios/bioscalls.c - pnpbios_print_status() Tried adding pnpbios=off, but with that the system does not boot anymore. Being curious, why a non-existing docking-station is being polled at regular intervals (i.e. every 2 seconds - see drivers/pnp/pnpbios/core.c ) From http://books.google.de/books?id=ibLa4I5EnC4Cpg=PA231lpg=PA231dq=pnp+docking+biossource=blots=ekCFm34U_Bsig=9Z9L55IAL7_3NtuM10jT3serncMhl=desa=Xei=mAZcVILnJsviO-r5gNgIved=0CCsQ6AEwAQ#v=onepageq=pnp%20docking%20biosf=false i read: Function 05h - Get Docking Status Information at page 251 it seems this is being the result of a docking event ? Does this mean, my system is erroneusly generating such docking events, even if there is no docking station at all? regards roland ps: i`m booting via plopKexec Bootloader ( http://www.plop.at/de/plopkexec.html ) , as i can put kernel+rootfs on external usb and don`t need to reflash the device, which is complicated task. pps: some few old pointers from other people reporting it: https://lists.debian.org/debian-kernel/2005/02/msg00238.html http://sourceforge.net/p/open-evot20/mailman/message/20065770/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Live-CD with recent kernel from kernel.org ?
hi, does anybody know if there is a linux live-cd which contains recent kernels from kernel.org and which is updated on a regular basis to incolude most recent kernel releases? I mean some live cd which is updated/remastered via an (semi-)automated process with focus on running the latest linux kernel. I searched for that for a while but did not find any. regards roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Live-CD with recent kernel from kernel.org ?
hi, does anybody know if there is a linux live-cd which contains recent kernels from kernel.org and which is updated on a regular basis to incolude most recent kernel releases? I mean some live cd which is updated/remastered via an (semi-)automated process with focus on running the latest linux kernel. I searched for that for a while but did not find any. regards roland -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Grub2 skips standard linux initialization code ?
Hi, regarding https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/930447 Grub2 "accidentally" heals a problem for systems which cannot boot PAE enabled kernels. This happens because grub2 apparently jumps into the kernel at a different entry point, so CPUID checking (check for PAE for example) apparently does not occur. Here are some 100 affected users (including me) which cannot boot recent Ubuntu (not even lubuntu, which is meant for that) Installation disk on their older hardware, which makes installation a pain. This is because Pentium M cpu´s for example often can do PAE, but they incorrectly report. The ubuntu installer disc does "traditional" boot via syslinux, whereas the installed system boots via grub2. That explains why you can upgrade from ubuntu 12.04 to 13.10 and have a workable system, but you cannot freshly install 13.10. The most absurd thing is: You cannot even install Lubuntu or Xubuntu, which is especially designed to be used on older hardware. I guess Pentium M is a process which is still widely used. My question is: 1. Why does Grub2 think it`s good to skip x86 linux initializiation code? Is that good or bad? 2. Besides that, wouldn`t it be extremly helpful to add a quirk or skip routine to the kernel initialization code? (kernelparam: "no-pae-ceck" for example). regards roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Grub2 skips standard linux initialization code ?
Hi, regarding https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/930447 Grub2 accidentally heals a problem for systems which cannot boot PAE enabled kernels. This happens because grub2 apparently jumps into the kernel at a different entry point, so CPUID checking (check for PAE for example) apparently does not occur. Here are some 100 affected users (including me) which cannot boot recent Ubuntu (not even lubuntu, which is meant for that) Installation disk on their older hardware, which makes installation a pain. This is because Pentium M cpu´s for example often can do PAE, but they incorrectly report. The ubuntu installer disc does traditional boot via syslinux, whereas the installed system boots via grub2. That explains why you can upgrade from ubuntu 12.04 to 13.10 and have a workable system, but you cannot freshly install 13.10. The most absurd thing is: You cannot even install Lubuntu or Xubuntu, which is especially designed to be used on older hardware. I guess Pentium M is a process which is still widely used. My question is: 1. Why does Grub2 think it`s good to skip x86 linux initializiation code? Is that good or bad? 2. Besides that, wouldn`t it be extremly helpful to add a quirk or skip routine to the kernel initialization code? (kernelparam: no-pae-ceck for example). regards roland -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allow NBD to be used locally
> How will that work? Fuse makes up a filesystem - not helpful > if you have a raw disk without a known fs to mount. take zfs-fuse or ntfs-3g for example. you have a blockdevice or backing-file containing data structures and fuse makes those show up as a filesystem. i think vmware-mount is not different here. > This still does not account for compressed disk images, for example. unfortunately, not > > > On Feb 2 2008 15:40, [EMAIL PROTECTED] wrote: > > > >>In fact, VMware uses local nbd today for its vmware-loop helper > >>utility, most likely because of the above-mentioned reasons. (Though > >>it quite often hung last time I tried.) > > > >seems this will go away. recent vmware versions (e.g. server 2.0 > >beta) have a fuse based replacement for that. > > How will that work? Fuse makes up a filesystem - not helpful > if you have a raw disk without a known fs to mount. > > >>So what we have is non-linearity -- LBA 22 comes after LBA 40 -- loop > >>does not deal with that. > > > >maybe dm-loop does? http://sources.redhat.com/lvm2/wiki/DMLoop > > This still does not account for compressed disk images, for example. > > Bis 50 MB Dateianhänge? Kein Problem! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allow NBD to be used locally
>In fact, VMware uses local nbd today for its vmware-loop helper >utility, most likely because of the above-mentioned reasons. (Though >it quite often hung last time I tried.) seems this will go away. recent vmware versions (e.g. server 2.0 beta) have a fuse based replacement for that. ldd /usr/bin/vmware-mount linux-gate.so.1 => (0xe000) libz.so.1 => /lib/libz.so.1 (0xb7f95000) ! -> libfuse.so.2 => /lib/libfuse.so.2 (0xb7f79000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7f61000) libdl.so.2 => /lib/libdl.so.2 (0xb7f5d000) libc.so.6 => /lib/libc.so.6 (0xb7e1c000) /lib/ld-linux.so.2 (0xb7fbd000) librt.so.1 => /lib/librt.so.1 (0xb7e13000) i`m not sure if this is the perfect approach (slower) , but at least that shouldn`t have those stability issues as the nbd one. i always felt uncomfortable with the nbd approach...that`s why i started the following discussion-thread: http://communities.vmware.com/message/854746 anyway, i can see a point to use nbd locally, but i think it shouldn`t be abused for mapping local disk-images of any kind, even if this has better capabilities than loop or other. why should local disk data be sent trough the network layer? isn`t device-mapper the better infrastructure here? >So what we have is non-linearity -- LBA 22 comes after LBA 40 -- loop >does not deal with that. maybe dm-loop does? http://sources.redhat.com/lvm2/wiki/DMLoop regards roland >On Feb 2 2008 12:23, Pavel Machek wrote: >>On Fri 2008-02-01 14:25:32, Laurent Vivier wrote: >>> This patch allows Network Block Device to be mounted locally. >> >>What is local nbd good for? Use loop instead... > >Local NBD is good for when the content you want to make available >through the block device is dynamic (generated on-the-fly), >non-linear or supersparse. > >Take for example VMware virtual disks. Just a guess, but >they roughly can look like this: > > kilobytes 0.. 1: header > kilobytes 1..10: correspond to LBA 0..20 > kilobytes 11..20: correspond to LBA 40..60 > kilobytes 21..22: correspond to LBA 22..23 > >So what we have is non-linearity -- LBA 22 comes after LBA 40 -- loop >does not deal with that. > >And there is supersparsity -- the VMDK file itself is complete, but >unallocated regions like LBA 24..40 are sparse/zero when projected >onto a file/block device, respectively; loop cannot deal with that >either. > >In fact, VMware uses local nbd today for its vmware-loop helper >utility, most likely because of the above-mentioned reasons. (Though >it quite often hung last time I tried.) _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux VM completely lost it`s timesource !?
cat /sys/devices/system/clocksource/clocksource0/current_clocksource acpi_pm cannot switch to any other clocksource, "echo tsc|jiffies|pit >current_clocksource" doesn`t have any effect. current_clocksource stays at acpi_pm maybe somebody has a clue what to check besides this? thanks roland >I`m running 2.6.24 kernel in a recent version of vmware workstation and i`m >unsure if \ >i hit a linux issue or a vmware issue here. > >after suspend/resume (hibernate) of my physical system (win xp), the linux >guest \ >seems to have lost itŽs timesource. > >don`t know much about timers in linux, so let me explain first: > >the guest was running when i suspended the xp host. >the xp host is running fine after resume. >the guest has issues. > >triggering a console beep inside the linux VM now doesn`t give a short beep >but \ >terrorizing me with a never-ending continuous beep. > >seems to be a timer issue inside the guest, since tools like top, vmstat, >watch etc \ >don`t work anymore. the system clock gone crazy, too - it`s counting from >22:40:47 to \ >22:40:51 and then constantly jumps back to 22:40:47 > >can someone give an advice what to check to make sure that this is NOT a linux >issue \ >? i will contact vmware then afterwards. > >regards >roland > >ps: >i did a snapshot of the VM and could preserve the state of the system this way. Bis 50 MB Dateianhänge? Kein Problem! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [clocksource] jiffies as clocksource kills box
>I have a patch pending for the PIT issue. Will add jiffies to this as >well. yes, please. while trying to analyze a timer issue and learning about that timer stuff, i "killed" my box twice because i didn`t know that "echo jiffies|pit > current_clocksource" is a no-no with dynticks. this happened with vendor kernel and thought i hit a bug, so i tried vanilla but.same issue. not a big one, but that patch would be a time-saver for those who don`t know... roland >> Per $subject, echo jiffies > current_clocksource pretty thoroughly kills >> my P4 box, and does so with every kernel I have (2.6.22->present). I >> can drive the box via mouse clicks and poke around, but trying to select >> another clocksource thereafter is nogo.. cat current_clocksource emits >> jiffies, and box remains comatose unless prodded. > >I guess your box has high resolution timers and/or dynamic ticks >enabled. In that case we really can not switch to jiffies. We also >have to prevent PIT from being selected. > >I have a patch pending for the PIT issue. Will add jiffies to this as >well. > >We'll fix that in .25 as it requires root user interaction and does >not show up magically. > >Thanks, > tglx _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [clocksource] jiffies as clocksource kills box
I have a patch pending for the PIT issue. Will add jiffies to this as well. yes, please. while trying to analyze a timer issue and learning about that timer stuff, i killed my box twice because i didn`t know that echo jiffies|pit current_clocksource is a no-no with dynticks. this happened with vendor kernel and thought i hit a bug, so i tried vanilla but.same issue. not a big one, but that patch would be a time-saver for those who don`t know... roland Per $subject, echo jiffies current_clocksource pretty thoroughly kills my P4 box, and does so with every kernel I have (2.6.22-present). I can drive the box via mouse clicks and poke around, but trying to select another clocksource thereafter is nogo.. cat current_clocksource emits jiffies, and box remains comatose unless prodded. I guess your box has high resolution timers and/or dynamic ticks enabled. In that case we really can not switch to jiffies. We also have to prevent PIT from being selected. I have a patch pending for the PIT issue. Will add jiffies to this as well. We'll fix that in .25 as it requires root user interaction and does not show up magically. Thanks, tglx _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux VM completely lost it`s timesource !?
cat /sys/devices/system/clocksource/clocksource0/current_clocksource acpi_pm cannot switch to any other clocksource, echo tsc|jiffies|pit current_clocksource doesn`t have any effect. current_clocksource stays at acpi_pm maybe somebody has a clue what to check besides this? thanks roland I`m running 2.6.24 kernel in a recent version of vmware workstation and i`m unsure if \ i hit a linux issue or a vmware issue here. after suspend/resume (hibernate) of my physical system (win xp), the linux guest \ seems to have lost itŽs timesource. don`t know much about timers in linux, so let me explain first: the guest was running when i suspended the xp host. the xp host is running fine after resume. the guest has issues. triggering a console beep inside the linux VM now doesn`t give a short beep but \ terrorizing me with a never-ending continuous beep. seems to be a timer issue inside the guest, since tools like top, vmstat, watch etc \ don`t work anymore. the system clock gone crazy, too - it`s counting from 22:40:47 to \ 22:40:51 and then constantly jumps back to 22:40:47 can someone give an advice what to check to make sure that this is NOT a linux issue \ ? i will contact vmware then afterwards. regards roland ps: i did a snapshot of the VM and could preserve the state of the system this way. Bis 50 MB Dateianhänge? Kein Problem! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allow NBD to be used locally
In fact, VMware uses local nbd today for its vmware-loop helper utility, most likely because of the above-mentioned reasons. (Though it quite often hung last time I tried.) seems this will go away. recent vmware versions (e.g. server 2.0 beta) have a fuse based replacement for that. ldd /usr/bin/vmware-mount linux-gate.so.1 = (0xe000) libz.so.1 = /lib/libz.so.1 (0xb7f95000) ! - libfuse.so.2 = /lib/libfuse.so.2 (0xb7f79000) libpthread.so.0 = /lib/libpthread.so.0 (0xb7f61000) libdl.so.2 = /lib/libdl.so.2 (0xb7f5d000) libc.so.6 = /lib/libc.so.6 (0xb7e1c000) /lib/ld-linux.so.2 (0xb7fbd000) librt.so.1 = /lib/librt.so.1 (0xb7e13000) i`m not sure if this is the perfect approach (slower) , but at least that shouldn`t have those stability issues as the nbd one. i always felt uncomfortable with the nbd approach...that`s why i started the following discussion-thread: http://communities.vmware.com/message/854746 anyway, i can see a point to use nbd locally, but i think it shouldn`t be abused for mapping local disk-images of any kind, even if this has better capabilities than loop or other. why should local disk data be sent trough the network layer? isn`t device-mapper the better infrastructure here? So what we have is non-linearity -- LBA 22 comes after LBA 40 -- loop does not deal with that. maybe dm-loop does? http://sources.redhat.com/lvm2/wiki/DMLoop regards roland On Feb 2 2008 12:23, Pavel Machek wrote: On Fri 2008-02-01 14:25:32, Laurent Vivier wrote: This patch allows Network Block Device to be mounted locally. What is local nbd good for? Use loop instead... Local NBD is good for when the content you want to make available through the block device is dynamic (generated on-the-fly), non-linear or supersparse. Take for example VMware virtual disks. Just a guess, but they roughly can look like this: kilobytes 0.. 1: header kilobytes 1..10: correspond to LBA 0..20 kilobytes 11..20: correspond to LBA 40..60 kilobytes 21..22: correspond to LBA 22..23 So what we have is non-linearity -- LBA 22 comes after LBA 40 -- loop does not deal with that. And there is supersparsity -- the VMDK file itself is complete, but unallocated regions like LBA 24..40 are sparse/zero when projected onto a file/block device, respectively; loop cannot deal with that either. In fact, VMware uses local nbd today for its vmware-loop helper utility, most likely because of the above-mentioned reasons. (Though it quite often hung last time I tried.) _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allow NBD to be used locally
How will that work? Fuse makes up a filesystem - not helpful if you have a raw disk without a known fs to mount. take zfs-fuse or ntfs-3g for example. you have a blockdevice or backing-file containing data structures and fuse makes those show up as a filesystem. i think vmware-mount is not different here. This still does not account for compressed disk images, for example. unfortunately, not On Feb 2 2008 15:40, [EMAIL PROTECTED] wrote: In fact, VMware uses local nbd today for its vmware-loop helper utility, most likely because of the above-mentioned reasons. (Though it quite often hung last time I tried.) seems this will go away. recent vmware versions (e.g. server 2.0 beta) have a fuse based replacement for that. How will that work? Fuse makes up a filesystem - not helpful if you have a raw disk without a known fs to mount. So what we have is non-linearity -- LBA 22 comes after LBA 40 -- loop does not deal with that. maybe dm-loop does? http://sources.redhat.com/lvm2/wiki/DMLoop This still does not account for compressed disk images, for example. Bis 50 MB Dateianhänge? Kein Problem! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux VM completely lost it`s timesource !?
Hi ! I`m running 2.6.24 kernel in a recent version of vmware workstation and i`m unsure if i hit a linux issue or a vmware issue here. after suspend/resume (hibernate) of my physical system (win xp), the linux guest seems to have lost itŽs timesource. don`t know much about timers in linux, so let me explain first: the guest was running when i suspended the xp host. the xp host is running fine after resume. the guest has issues. triggering a console beep inside the linux VM now doesn`t give a short beep but terrorizing me with a never-ending continuous beep. seems to be a timer issue inside the guest, since tools like top, vmstat, watch etc don`t work anymore. the system clock gone crazy, too - it`s counting from 22:40:47 to 22:40:51 and then constantly jumps back to 22:40:47 can someone give an advice what to check to make sure that this is NOT a linux issue ? i will contact vmware then afterwards. regards roland ps: i did a snapshot of the VM and could preserve the state of the system this way. Bis 50 MB Dateianhänge? Kein Problem! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux VM completely lost it`s timesource !?
Hi ! I`m running 2.6.24 kernel in a recent version of vmware workstation and i`m unsure if i hit a linux issue or a vmware issue here. after suspend/resume (hibernate) of my physical system (win xp), the linux guest seems to have lost itŽs timesource. don`t know much about timers in linux, so let me explain first: the guest was running when i suspended the xp host. the xp host is running fine after resume. the guest has issues. triggering a console beep inside the linux VM now doesn`t give a short beep but terrorizing me with a never-ending continuous beep. seems to be a timer issue inside the guest, since tools like top, vmstat, watch etc don`t work anymore. the system clock gone crazy, too - it`s counting from 22:40:47 to 22:40:51 and then constantly jumps back to 22:40:47 can someone give an advice what to check to make sure that this is NOT a linux issue ? i will contact vmware then afterwards. regards roland ps: i did a snapshot of the VM and could preserve the state of the system this way. Bis 50 MB Dateianhänge? Kein Problem! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: introduce /dev/mem restrictions with a config option
nice ! did you think about some boot-time param , e.g. "insecure-devmem" or something like that? recompiling kernel is time consuming. From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [PATCH] x86: introduce /dev/mem restrictions with a config option This patch introduces a restriction on /dev/mem: Only non-memory can be read or written unless the newly introduced config option is set. The X server needs access to /dev/mem for the PCI space, but it doesn't need access to memory; both the file permissions and SELinux permissions of /dev/mem just make X effectively super-super powerful. With the exception of the BIOS area, there's just no valid app that uses /dev/mem on actual memory. Other popular users of /dev/mem are rootkits and the like. (note: mmap access of memory via /dev/mem was already not allowed since a really long time) People who want to use /dev/mem for kernel debugging can enable the config option. The restrictions of this patch have been in the Fedora and RHEL kernels for at least 4 years without any problems. Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: introduce /dev/mem restrictions with a config option
nice ! did you think about some boot-time param , e.g. insecure-devmem or something like that? recompiling kernel is time consuming. From: Arjan van de Ven [EMAIL PROTECTED] Subject: [PATCH] x86: introduce /dev/mem restrictions with a config option This patch introduces a restriction on /dev/mem: Only non-memory can be read or written unless the newly introduced config option is set. The X server needs access to /dev/mem for the PCI space, but it doesn't need access to memory; both the file permissions and SELinux permissions of /dev/mem just make X effectively super-super powerful. With the exception of the BIOS area, there's just no valid app that uses /dev/mem on actual memory. Other popular users of /dev/mem are rootkits and the like. (note: mmap access of memory via /dev/mem was already not allowed since a really long time) People who want to use /dev/mem for kernel debugging can enable the config option. The restrictions of this patch have been in the Fedora and RHEL kernels for at least 4 years without any problems. Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc9 kernel panic - simple_map_write+0x4e/0x75
looks very similar to http://marc.info/?l=linux-kernel=119759817332220=2 http://marc.info/?l=linux-kernel=119902059626408=2 http://marc.info/?l=linux-kernel=119259674826979=2 http://lkml.org/lkml/2006/6/14/59 so you should try without CONFIG_MTD_PNC2000 that driver having problems for some time (first report seems 2.6.17 ) - i have found same issue (independently) on 2.6.22 and 2.6.24, too. i have some updated information regarding this driver i will post here very soon, but please confirm if this is the issue here (i`m quite sure it is) regards roland Subject:Re: [BUG] 2.6.23-rc9 kernel panic - simple_map_write+0x4e/0x75 From: Kamalesh Babulal Date: 2007-10-17 7:23:33 Message-ID: 4715B5A5.9050005 () linux ! vnet ! ibm ! com [Download message RAW] Andrew Morton wrote: > On Sat, 13 Oct 2007 12:10:44 +0530 > Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > >> Kernel panic's with following oops message with 2.6.23-rc9 kernel >> >> [ 320.747257] ks0108: ERROR: parport didn't register new device >> [ 320.771314] cfag12864b: ERROR: ks0108 is not initialized >> [ 320.794308] cfag12864bfb: ERROR: cfag12864b is not initialized >> [ 320.820729] BUG: unable to handle kernel paging request at virtual address >> bf00 >> [ 320.857712] printing eip: >> [ 320.872556] *pde = >> [ 320.887577] Oops: 0002 [#1] >> [ 320.902383] SMP >> [ 320.914174] Modules linked in: >> [ 320.929333] CPU:0 >> [ 320.929334] EIP:0060:[]Not tainted VLI >> [ 320.929335] EFLAGS: 00010286 (2.6.23-rc9-1 #1) >> [ 320.982753] EIP is at simple_map_write+0x4e/0x75 >> [ 321.001956] eax: f0f0f0f0 ebx: c1de3f00 ecx: c1de3f00 edx: c1de3f00 >> [ 321.027701] esi: c3ca8d6c edi: bf00 ebp: c3ca8d98 esp: c3ca8d6c >> [ 321.053322] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 >> [ 321.075981] Process swapper (pid: 1, ti=c3ca8000 task=f7f44000 >> task.ti=c3ca8000) >> [ 321.103031] Stack: f0f0f0f0 >> >> [ 321.139446]c3ca8e20 0001 c3ca8e40 c3ca8e6c c0d692e6 f0f0f0f0 >> >> [ 321.176495] >> 50e6 >> [ 321.214141] Call Trace: >> [ 321.233922] [] show_trace_log_lvl+0x19/0x2e >> [ 321.255433] [] show_stack_log_lvl+0x99/0xa1 >> [ 321.276706] [] show_registers+0x1b8/0x290 >> [ 321.297254] [] die+0x118/0x1fd >> [ 321.314920] [] do_page_fault+0x51c/0x5f3 >> [ 321.335291] [] error_code+0x72/0x78 >> [ 321.354413] [] cfi_probe_chip+0x148/0x9e1 >> [ 321.375202] [] genprobe_new_chip+0x82/0x98 >> [ 321.396298] [] genprobe_ident_chips+0x26/0x205 >> [ 321.418493] [] mtd_do_chip_probe+0x10/0x97 >> [ 321.439654] [] cfi_probe+0xd/0xf >> [ 321.458157] [] do_map_probe+0x40/0x53 >> [ 321.477931] [] init_pnc2000+0x3b/0x6d >> [ 321.497559] [] do_initcalls+0x7a/0x1c2 >> [ 321.517377] [] do_basic_setup+0x1c/0x1e >> [ 321.537327] [] kernel_init+0x69/0xaa >> [ 321.556311] [] kernel_thread_helper+0x7/0x10 >> [ 321.577207] === >> [ 321.592882] Code: 83 f8 01 75 0a 03 7b 10 8b 45 d4 88 07 eb 35 83 f8 02 >> 75 0c >> 0f b7 45 d4 03 7b 10 66 89 07 eb 24 83 f8 04 75 0a 03 7b 10 8b 45 d4 <89> 07 >> eb >> 15 7e 13 03 7b 10 89 c1 c1 e9 02 f3 a5 89 c1 83 e1 03 >> [ 321.668990] EIP: [] simple_map_write+0x4e/0x75 SS:ESP >> 0068:c3ca8d6c >> [ 321.695750] Kernel panic - not syncing: Attempted to kill init! > > Would I be correct in assuming that the machine has no mtd devices, but > you happened to link that driver into your vmlinux? > Hi Andrew, The machine do not have the mtd device, and the mtd is compiled into the vmlinuz. This configuration works fine for other kernels and is reproducible with 2.6.23-rc9 only. -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. _ Unbegrenzter Speicherplatz für Ihr E-Mail Postfach? Jetzt aktivieren! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc9 kernel panic - simple_map_write+0x4e/0x75
looks very similar to http://marc.info/?l=linux-kernelm=119759817332220w=2 http://marc.info/?l=linux-kernelm=119902059626408w=2 http://marc.info/?l=linux-kernelm=119259674826979w=2 http://lkml.org/lkml/2006/6/14/59 so you should try without CONFIG_MTD_PNC2000 that driver having problems for some time (first report seems 2.6.17 ) - i have found same issue (independently) on 2.6.22 and 2.6.24, too. i have some updated information regarding this driver i will post here very soon, but please confirm if this is the issue here (i`m quite sure it is) regards roland Subject:Re: [BUG] 2.6.23-rc9 kernel panic - simple_map_write+0x4e/0x75 From: Kamalesh Babulal kamalesh () linux ! vnet ! ibm ! com Date: 2007-10-17 7:23:33 Message-ID: 4715B5A5.9050005 () linux ! vnet ! ibm ! com [Download message RAW] Andrew Morton wrote: On Sat, 13 Oct 2007 12:10:44 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Kernel panic's with following oops message with 2.6.23-rc9 kernel [ 320.747257] ks0108: ERROR: parport didn't register new device [ 320.771314] cfag12864b: ERROR: ks0108 is not initialized [ 320.794308] cfag12864bfb: ERROR: cfag12864b is not initialized [ 320.820729] BUG: unable to handle kernel paging request at virtual address bf00 [ 320.857712] printing eip: [ 320.872556] *pde = [ 320.887577] Oops: 0002 [#1] [ 320.902383] SMP [ 320.914174] Modules linked in: [ 320.929333] CPU:0 [ 320.929334] EIP:0060:[c0d7e4e2]Not tainted VLI [ 320.929335] EFLAGS: 00010286 (2.6.23-rc9-1 #1) [ 320.982753] EIP is at simple_map_write+0x4e/0x75 [ 321.001956] eax: f0f0f0f0 ebx: c1de3f00 ecx: c1de3f00 edx: c1de3f00 [ 321.027701] esi: c3ca8d6c edi: bf00 ebp: c3ca8d98 esp: c3ca8d6c [ 321.053322] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [ 321.075981] Process swapper (pid: 1, ti=c3ca8000 task=f7f44000 task.ti=c3ca8000) [ 321.103031] Stack: f0f0f0f0 [ 321.139446]c3ca8e20 0001 c3ca8e40 c3ca8e6c c0d692e6 f0f0f0f0 [ 321.176495] 50e6 [ 321.214141] Call Trace: [ 321.233922] [c0107dff] show_trace_log_lvl+0x19/0x2e [ 321.255433] [c0107ec1] show_stack_log_lvl+0x99/0xa1 [ 321.276706] [c01080c4] show_registers+0x1b8/0x290 [ 321.297254] [c01082f9] die+0x118/0x1fd [ 321.314920] [c145014a] do_page_fault+0x51c/0x5f3 [ 321.335291] [c144e6da] error_code+0x72/0x78 [ 321.354413] [c0d692e6] cfi_probe_chip+0x148/0x9e1 [ 321.375202] [c0d7bb3e] genprobe_new_chip+0x82/0x98 [ 321.396298] [c0d7b8dd] genprobe_ident_chips+0x26/0x205 [ 321.418493] [c0d7b830] mtd_do_chip_probe+0x10/0x97 [ 321.439654] [c0d6a29e] cfi_probe+0xd/0xf [ 321.458157] [c0d68d57] do_map_probe+0x40/0x53 [ 321.477931] [c200d748] init_pnc2000+0x3b/0x6d [ 321.497559] [c1fa382c] do_initcalls+0x7a/0x1c2 [ 321.517377] [c1fa3990] do_basic_setup+0x1c/0x1e [ 321.537327] [c1fa3a2c] kernel_init+0x69/0xaa [ 321.556311] [c0107c2b] kernel_thread_helper+0x7/0x10 [ 321.577207] === [ 321.592882] Code: 83 f8 01 75 0a 03 7b 10 8b 45 d4 88 07 eb 35 83 f8 02 75 0c 0f b7 45 d4 03 7b 10 66 89 07 eb 24 83 f8 04 75 0a 03 7b 10 8b 45 d4 89 07 eb 15 7e 13 03 7b 10 89 c1 c1 e9 02 f3 a5 89 c1 83 e1 03 [ 321.668990] EIP: [c0d7e4e2] simple_map_write+0x4e/0x75 SS:ESP 0068:c3ca8d6c [ 321.695750] Kernel panic - not syncing: Attempted to kill init! Would I be correct in assuming that the machine has no mtd devices, but you happened to link that driver into your vmlinux? Hi Andrew, The machine do not have the mtd device, and the mtd is compiled into the vmlinuz. This configuration works fine for other kernels and is reproducible with 2.6.23-rc9 only. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. _ Unbegrenzter Speicherplatz für Ihr E-Mail Postfach? Jetzt aktivieren! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] fast file mapping for loop
oh, nice to see that this is still alive. i tried this around half a year ago because i needed more than 256 loop devices and iirc, this was working quite fine. at least i got no crashes and was able to mount and acess more than 300 iso-images with that. shortly after, loop device was extended to handle a larger number of loop-devices and i went that way because dm-loop was not in mainline. i have taken a look at the wiki at http://sources.redhat.com/lvm2/wiki/DMLoop from time to time, but there didn`t seem to happen much. were there fixes/chances since then? do you think it`s ready for mainline? >Here's the latest version of dm-loop, for comparison. > >To try it out, > ln -s dmsetup dmlosetup >and supply similar basic parameters to losetup. >(using dmsetup version 1.02.11 or higher) > >Alasdair > >From: Bryn Reeves <[EMAIL PROTECTED]> > >This implements a loopback target for device mapper allowing a regular >file to be treated as a block device. > >Signed-off-by: Bryn Reeves <[EMAIL PROTECTED]> >Signed-off-by: Alasdair G Kergon <[EMAIL PROTECTED]> __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] fast file mapping for loop
oh, nice to see that this is still alive. i tried this around half a year ago because i needed more than 256 loop devices and iirc, this was working quite fine. at least i got no crashes and was able to mount and acess more than 300 iso-images with that. shortly after, loop device was extended to handle a larger number of loop-devices and i went that way because dm-loop was not in mainline. i have taken a look at the wiki at http://sources.redhat.com/lvm2/wiki/DMLoop from time to time, but there didn`t seem to happen much. were there fixes/chances since then? do you think it`s ready for mainline? Here's the latest version of dm-loop, for comparison. To try it out, ln -s dmsetup dmlosetup and supply similar basic parameters to losetup. (using dmsetup version 1.02.11 or higher) Alasdair From: Bryn Reeves [EMAIL PROTECTED] This implements a loopback target for device mapper allowing a regular file to be treated as a block device. Signed-off-by: Bryn Reeves [EMAIL PROTECTED] Signed-off-by: Alasdair G Kergon [EMAIL PROTECTED] __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Size of kernel halts startup
Hi! >4) Yesterday, I have done a menuconfig and turned on some drivers (USB HID and >I2C). \ >This resulted in a kernel size of about 1.4MB. if you saved your old .config you could add those features one after the other to see if it`s size related >5) Booting up this 1.4MB kernel over NFS causes a register dump to appear and >the \ >system is halted. >Is this issue related to the size of the kernel or it is due to some conflict >in \ >memory ? hard to tell without any further information on this. >If it is related to size of kernel, how can the size be increased so as to >resolve \ >this issue ? i assume you meant decrease!? get a in-depth knowlegde about all the different config options and decide if you need it or not. maybe after compile, some find . -name "*.o" |while read file;do ls -s $file;done |sort -n will help identifying parts of the kernel which take up most of the space maybe CONFIG_EMBEDDED=y helps, too. furthermore, there are projects like http://www.selenic.com/linux-tiny/ to make kernel small for embedded systems. a nice (but more generic) article about downsizing linux for embedded system is at http://www.linuxjournal.com/article/9686 i think these mailing lists provide better help since it`s more likely to meet people there who develop for ARCH=arm http://marc.info/?l=linux-arm=1=2 http://marc.info/?l=linux-arm-kernel=1=2 regards roland >Appreciate any help and advises. > >Thanks in advance. > >Sim CK >List: linux-kernel >Subject:Size of kernel halts startup >From: cksim >Date: 2008-01-07 3:28:29 >Message-ID: 1199676509.47819c5deaf60 () discus ! singnet ! com ! sg >[Download message RAW] > >Hi, > >Yesterday, I have encountered an issue when the kernel size is more than 1.3MB. > >Info on problem encountered as follows: >1) I am using Atmel AT91SAM9261 part. Circuit similar to that of AT91SAM9261EK >evaluation board. > >2) I am booting the kernel through NFS. Bootloader >used is UBoot 1.1.5. Kernel used is 2.6.23.1 > >3) For the past weeks, the kernel size was about 1.3MB and kernel bootup over >NFS was \ >fine. > >4) Yesterday, I have done a menuconfig and turned on some drivers (USB HID and >I2C). \ >This resulted in a kernel size of about 1.4MB. > >5) Booting up this 1.4MB kernel over NFS causes a register dump to appear and >the \ >system is halted. > >Is this issue related to the size of the kernel or it is due to some conflict >in \ >memory ? > >If it is related to size of kernel, how can the size be increased so as to >resolve \ >this issue ? > >Appreciate any help and advises. > >Thanks in advance. > >Sim CK __ XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club! Jetzt testen! http://produkte.web.de/club/?mc=021130 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] show being-loaded/being-unloaded indic ator for modules
this looks very useful! >Unfortunatly, it's not always easy to see directly >which module is being loaded/unloaded from the oops itself. no wonder, as most modules seem to be very quiet on on load/unload. some days ago i was curious how "consistent" modules would leave messages in syslog load/unload. this is why i made a little statistic on that. i`d like to share the essential part here (can provide more details if you like): on load, 1204 on unload, 1655 (out of 2088) left absoultely _no_ message in syslog example: 3c359 - silence 3c501 - silence 3c503 - 2 lines on load, 0 on unload 3c505 - 3 lines on load, 0 on unload 3c507 - silence 3c509 - silence 3c515 - 1 line on load, 0 on unload 3c574_cs - silence 3c589_cs - silence 3c59x - silence ok, this is not too reliable, because modules might act differently if they find appropriate hardware. but i wonder if some mandatory "print a message on init/exit" wouldn`t give a benefit to admins or end-users, too. sure this would additionally clutter up syslog, but it would add transparency. if modules can print informations like credits, email-adresses and path-to-the-source-files, why not some mandatory message on load/unload then >List: linux-kernel >Subject:[patch 1/2] show being-loaded/being-unloaded indicator for modules >From: Arjan van de Ven >Date: 2008-01-06 23:18:50 >Message-ID: 20080106151850.3eab58b0 () laptopd505 ! fenrus ! org >[Download message RAW] > >Subject: show being-loaded/being-unloaded indicator for modules in oopses >From: Arjan van de Ven <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >CC: [EMAIL PROTECTED] >CC: [EMAIL PROTECTED] > >It's rather common that an oops/WARN_ON/BUG happens during the load or >unload of a module. Unfortunatly, it's not always easy to see directly >which module is being loaded/unloaded from the oops itself. Worse, >it's not even always possible to ask the bug reporter, since there >are so many components (udev etc) that auto-load modules that there's >a good chance that even the reporter doesn't know which module this is. > >This patch extends the existing "show if it's tainting" print code, >which is used as part of printing the modules in the oops/BUG/WARN_ON >to include a "+" for "being loaded" and a "-" for "being unloaded". >As a result this extension, the "taint_flags()" function gets renamed to >"module_flags()" (and takes a module struct as argument, not a taint >flags int). _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] show being-loaded/being-unloaded indic ator for modules
this looks very useful! Unfortunatly, it's not always easy to see directly which module is being loaded/unloaded from the oops itself. no wonder, as most modules seem to be very quiet on on load/unload. some days ago i was curious how consistent modules would leave messages in syslog load/unload. this is why i made a little statistic on that. i`d like to share the essential part here (can provide more details if you like): on load, 1204 on unload, 1655 (out of 2088) left absoultely _no_ message in syslog example: 3c359 - silence 3c501 - silence 3c503 - 2 lines on load, 0 on unload 3c505 - 3 lines on load, 0 on unload 3c507 - silence 3c509 - silence 3c515 - 1 line on load, 0 on unload 3c574_cs - silence 3c589_cs - silence 3c59x - silence ok, this is not too reliable, because modules might act differently if they find appropriate hardware. but i wonder if some mandatory print a message on init/exit wouldn`t give a benefit to admins or end-users, too. sure this would additionally clutter up syslog, but it would add transparency. if modules can print informations like credits, email-adresses and path-to-the-source-files, why not some mandatory message on load/unload then List: linux-kernel Subject:[patch 1/2] show being-loaded/being-unloaded indicator for modules From: Arjan van de Ven arjan () infradead ! org Date: 2008-01-06 23:18:50 Message-ID: 20080106151850.3eab58b0 () laptopd505 ! fenrus ! org [Download message RAW] Subject: show being-loaded/being-unloaded indicator for modules in oopses From: Arjan van de Ven [EMAIL PROTECTED] CC: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] It's rather common that an oops/WARN_ON/BUG happens during the load or unload of a module. Unfortunatly, it's not always easy to see directly which module is being loaded/unloaded from the oops itself. Worse, it's not even always possible to ask the bug reporter, since there are so many components (udev etc) that auto-load modules that there's a good chance that even the reporter doesn't know which module this is. This patch extends the existing show if it's tainting print code, which is used as part of printing the modules in the oops/BUG/WARN_ON to include a + for being loaded and a - for being unloaded. As a result this extension, the taint_flags() function gets renamed to module_flags() (and takes a module struct as argument, not a taint flags int). _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Size of kernel halts startup
Hi! 4) Yesterday, I have done a menuconfig and turned on some drivers (USB HID and I2C). \ This resulted in a kernel size of about 1.4MB. if you saved your old .config you could add those features one after the other to see if it`s size related 5) Booting up this 1.4MB kernel over NFS causes a register dump to appear and the \ system is halted. Is this issue related to the size of the kernel or it is due to some conflict in \ memory ? hard to tell without any further information on this. If it is related to size of kernel, how can the size be increased so as to resolve \ this issue ? i assume you meant decrease!? get a in-depth knowlegde about all the different config options and decide if you need it or not. maybe after compile, some find . -name *.o |while read file;do ls -s $file;done |sort -n will help identifying parts of the kernel which take up most of the space maybe CONFIG_EMBEDDED=y helps, too. furthermore, there are projects like http://www.selenic.com/linux-tiny/ to make kernel small for embedded systems. a nice (but more generic) article about downsizing linux for embedded system is at http://www.linuxjournal.com/article/9686 i think these mailing lists provide better help since it`s more likely to meet people there who develop for ARCH=arm http://marc.info/?l=linux-armr=1w=2 http://marc.info/?l=linux-arm-kernelr=1w=2 regards roland Appreciate any help and advises. Thanks in advance. Sim CK List: linux-kernel Subject:Size of kernel halts startup From: cksim cksim () singnet ! com ! sg Date: 2008-01-07 3:28:29 Message-ID: 1199676509.47819c5deaf60 () discus ! singnet ! com ! sg [Download message RAW] Hi, Yesterday, I have encountered an issue when the kernel size is more than 1.3MB. Info on problem encountered as follows: 1) I am using Atmel AT91SAM9261 part. Circuit similar to that of AT91SAM9261EK evaluation board. 2) I am booting the kernel through NFS. Bootloader used is UBoot 1.1.5. Kernel used is 2.6.23.1 3) For the past weeks, the kernel size was about 1.3MB and kernel bootup over NFS was \ fine. 4) Yesterday, I have done a menuconfig and turned on some drivers (USB HID and I2C). \ This resulted in a kernel size of about 1.4MB. 5) Booting up this 1.4MB kernel over NFS causes a register dump to appear and the \ system is halted. Is this issue related to the size of the kernel or it is due to some conflict in \ memory ? If it is related to size of kernel, how can the size be increased so as to resolve \ this issue ? Appreciate any help and advises. Thanks in advance. Sim CK __ XXL-Speicher, PC-Virenschutz, Spartarife mehr: Nur im WEB.DE Club! Jetzt testen! http://produkte.web.de/club/?mc=021130 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PIT clocksource makes invalid assumptions
>I also didn't do a whole lot of digging to see what the problems this >bug can cause in practice, but after the PIT clocksource was installed, >I tried 'sleep 1' and this did not wake up. i`m using clock=pit on many of our virtual servers for accurate time syncronization. (as recommended by vmware and even by microsoft - see: http://support.microsoft.com/?scid=kb%3Ben-us%3B918461=11=18 ) so this means i need "clock=pit nohz=off" now on those systems, if this won`t get fixed? On 01/04/2008 12:18 PM, john stultz wrote: > On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote: >> Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT >> clocksource code assumes that the PIT CH0 is in periodic mode. With >> clockevents, this assumption is no longer valid. There are at least two >> places that make this assumption: >> >> 1) The calculation at the end of pit_read() assumes that the PIT is in >> periodic mode. This isn't true unless the PIT is the current clockevent >> and nohz is inactive. (Though #2 can end up forcing the PIT to be >> reprogrammed). >> >> 2) The PIT clockevent is shutdown by using PIT mode 0 (interrupt on >> terminal count) -- doesn't the PIT counter continue to count (even >> though it won't be raising an interrupt)? If so, the test in pit_read() >> under the VIA686a comment can succeed after the PIT clockevent has been >> shutdown, and the PIT hardware may be reprogrammed to start firing >> interrupts again. This doesn't seem intentional, and can defeat nohz >> since now the PIT is firing periodically. >> >> Seems these problems can happen when the PIT is used as the clocksource >> or even just the clocksource watchdog. It looks like there is some code >> in clocksource.c that checks for CLOCK_SOURCE_IS_CONTINUOUS, which is >> not set for the PIT clocksource, but it doesn't seem to be strong enough >> to prevent these problematic scenarios (and it's not clear if that is >> the intent of IS_CONTINUOUS anyway). > > The clocksource in use must have IS_CONTINUOUS set before we go into > HRT/no_hz mode, so I think the situations above should not be possible > (although I've not had a chance to check the current code). > Yes, I think that is correct. But, I don't think the code (always) prevents nohz mode when the clocksource *watchdog* is !IS_CONTINUOUS. Anyway, the bug doesn't require that nohz mode is enabled, it just requires that the PIT clockevent is shutdown (or otherwise not programmed in periodic mode). >> To verify this really can happen, when I boot a kernel, I can see this >> sequence: >> >>init_pit_timer (with mode==CLOCK_EVT_MODE_PERIODIC) >>init_pit_timer (with mode==CLOCK_EVT_MODE_UNUSED) >>init_pit_timer (with mode==CLOCK_EVT_MODE_SHUTDOWN) >>pit_read() and count > LATCH (I believe the PIT is the watchdog at >> this point), which causes the PIT to raise periodic interrupts. >> >> (Shortly after, the acpi pm clocksource is registered and replaces the >> PIT as the watchdog. Later, the PIT clockevent is used as the broadcast >> clockevent and reprogrammed into one-shot mode, stopping the PIT >> interrupts.) >> >> Also, the user could force the PIT clocksource to be current_clocksource >> even though the PIT is in one-shot mode (and therefore the calculation >> in pit_read is bogus). > > Does this actually happen and cause problems? I thought there was some > code to make sure we disable HRT/no_hz if we install a clocksource that > does not have IS_CONTINUOUS set. > I didn't check if nohz was disabled when the PIT clocksource is switched to, but I did check that the PIT was not the active clockevent, which is enough for this bug. I also didn't do a whole lot of digging to see what the problems this bug can cause in practice, but after the PIT clocksource was installed, I tried 'sleep 1' and this did not wake up. Thanks, Dan _ In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PIT clocksource makes invalid assumptions
I also didn't do a whole lot of digging to see what the problems this bug can cause in practice, but after the PIT clocksource was installed, I tried 'sleep 1' and this did not wake up. i`m using clock=pit on many of our virtual servers for accurate time syncronization. (as recommended by vmware and even by microsoft - see: http://support.microsoft.com/?scid=kb%3Ben-us%3B918461x=11y=18 ) so this means i need clock=pit nohz=off now on those systems, if this won`t get fixed? On 01/04/2008 12:18 PM, john stultz wrote: On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote: Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT clocksource code assumes that the PIT CH0 is in periodic mode. With clockevents, this assumption is no longer valid. There are at least two places that make this assumption: 1) The calculation at the end of pit_read() assumes that the PIT is in periodic mode. This isn't true unless the PIT is the current clockevent and nohz is inactive. (Though #2 can end up forcing the PIT to be reprogrammed). 2) The PIT clockevent is shutdown by using PIT mode 0 (interrupt on terminal count) -- doesn't the PIT counter continue to count (even though it won't be raising an interrupt)? If so, the test in pit_read() under the VIA686a comment can succeed after the PIT clockevent has been shutdown, and the PIT hardware may be reprogrammed to start firing interrupts again. This doesn't seem intentional, and can defeat nohz since now the PIT is firing periodically. Seems these problems can happen when the PIT is used as the clocksource or even just the clocksource watchdog. It looks like there is some code in clocksource.c that checks for CLOCK_SOURCE_IS_CONTINUOUS, which is not set for the PIT clocksource, but it doesn't seem to be strong enough to prevent these problematic scenarios (and it's not clear if that is the intent of IS_CONTINUOUS anyway). The clocksource in use must have IS_CONTINUOUS set before we go into HRT/no_hz mode, so I think the situations above should not be possible (although I've not had a chance to check the current code). Yes, I think that is correct. But, I don't think the code (always) prevents nohz mode when the clocksource *watchdog* is !IS_CONTINUOUS. Anyway, the bug doesn't require that nohz mode is enabled, it just requires that the PIT clockevent is shutdown (or otherwise not programmed in periodic mode). To verify this really can happen, when I boot a kernel, I can see this sequence: init_pit_timer (with mode==CLOCK_EVT_MODE_PERIODIC) init_pit_timer (with mode==CLOCK_EVT_MODE_UNUSED) init_pit_timer (with mode==CLOCK_EVT_MODE_SHUTDOWN) pit_read() and count LATCH (I believe the PIT is the watchdog at this point), which causes the PIT to raise periodic interrupts. (Shortly after, the acpi pm clocksource is registered and replaces the PIT as the watchdog. Later, the PIT clockevent is used as the broadcast clockevent and reprogrammed into one-shot mode, stopping the PIT interrupts.) Also, the user could force the PIT clocksource to be current_clocksource even though the PIT is in one-shot mode (and therefore the calculation in pit_read is bogus). Does this actually happen and cause problems? I thought there was some code to make sure we disable HRT/no_hz if we install a clocksource that does not have IS_CONTINUOUS set. I didn't check if nohz was disabled when the PIT clocksource is switched to, but I did check that the PIT was not the active clockevent, which is enough for this bug. I also didn't do a whole lot of digging to see what the problems this bug can cause in practice, but after the PIT clocksource was installed, I tried 'sleep 1' and this did not wake up. Thanks, Dan _ In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Remove clutter from what modules print to dmesg
Hi ! while insanely looping trough a driver load/unload, i had taken a look at dmesg afterwards (i.e. after each modular driver had been loaded/unloaded once) besides some other things that probably could be point of discussion, i saw noticeable clutter. (this is an admin`s point of view) below is a list of that clutter (much of that is in ALSA or drivers/usb/serial btw) left side as it is now, right side a "cleaned" version as i think it looks better. imho the latter would be more consistent output , since it`s mostly "modulename: .." when a module has something to tell (if it tells anything at all) let that be sort of a "standardization approach" to what modules print to dmesg. cleaning this as proposed would shrink my dmesg output by ~1% since i`m a such a kernel-hacking rookie and an appropriate patch would poke around in a lot of code, please tell me if such patch would be welcomed at all, so i wouldn`t waste time on this. regards roland with clutter |without clutter 3c503.c: Presently autoprobing (not recommended) for a single | 3c503: Presently autoprobing (not recommended) for a single c 3c503.c: No 3c503 card found (i/o = 0x0). | 3c503: No 3c503 card found (i/o = 0x0). 3c505.c: warning, using default DMA channel, | 3c505: warning, using default DMA channel, 3c505.c: module autoprobe not recommended, give io=xx.| 3c505: module autoprobe not recommended, give io=xx. 3c505.c: Failed to register card at 0x0. | 3c505: Failed to register card at 0x0. 3c515.c:v0.99t-ac 28-Oct-2002 [EMAIL PROTECTED] and others | 3c515:v0.99t-ac 28-Oct-2002 [EMAIL PROTECTED] and others tms380tr.c: v1.10 30/12/2002 by Christoph Goos, Adam Fritzler | tms380tr: v1.10 30/12/2002 by Christoph Goos, Adam Fritzler ac3200.c: No ac3200 card found (i/o = 0x0). | ac3200: No ac3200 card found (i/o = 0x0). drivers/input/tablet/acecad.c: v3.2:USB Acecad Flair tablet d | acecad: v3.2:USB Acecad Flair tablet driver drivers/usb/misc/adutux.c: adutux adutux (see www.ontrak.net) | adutux: adutux adutux (see www.ontrak.net) v0.0.13 drivers/usb/misc/adutux.c: adutux is an experimental driver. | adutux: adutux is an experimental driver. Use at your own ris drivers/input/tablet/aiptek.c: v2.3 (May 2, 2007): Bryan W. H | aiptek: v2.3 (May 2, 2007): Bryan W. Headley/Chris Atenasio/C drivers/input/tablet/aiptek.c: Aiptek HyperPen USB Tablet Dri | aiptek: Aiptek HyperPen USB Tablet Driver (Linux 2.6.x) drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for generic drivers/usb/serial/usb-serial.c: USB Serial Driver core | usb-serial: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for aircable drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver aircable drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver generic airo(): Probing for PCI adapters | airo: Probing for PCI adapters airo(): Finished probing for PCI adapters | airo: Finished probing for PCI adapters airo(): Probing for PCI adapters | airo: Probing for PCI adapters airo(): Finished probing for PCI adapters | airo: Finished probing for PCI adapters drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for generic drivers/usb/serial/usb-serial.c: USB Serial Driver core | usb-serial: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for airprime drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver airprime drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver generic drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for generic drivers/usb/serial/usb-serial.c: USB Serial Driver core | usb-serial: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for ark3116 drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver ark3116 drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver generic drivers/input/misc/ati_remote.c: Registered USB driver ATI/X1 | ati_remote: Registered USB driver ATI/X10 RF USB Remote Contr atp.c:v1.09=ac 2002/10/01 Donald Becker <[EMAIL PROTECTED]>| atp:v1.09=ac 2002/10/01 Donald Becker <[EMAIL PROTECTED]> drivers/usb/serial/usb-serial.c: USB Serial
[RFC] Remove clutter from what modules print to dmesg
Hi ! while insanely looping trough a driver load/unload, i had taken a look at dmesg afterwards (i.e. after each modular driver had been loaded/unloaded once) besides some other things that probably could be point of discussion, i saw noticeable clutter. (this is an admin`s point of view) below is a list of that clutter (much of that is in ALSA or drivers/usb/serial btw) left side as it is now, right side a cleaned version as i think it looks better. imho the latter would be more consistent output , since it`s mostly modulename: .. when a module has something to tell (if it tells anything at all) let that be sort of a standardization approach to what modules print to dmesg. cleaning this as proposed would shrink my dmesg output by ~1% since i`m a such a kernel-hacking rookie and an appropriate patch would poke around in a lot of code, please tell me if such patch would be welcomed at all, so i wouldn`t waste time on this. regards roland with clutter |without clutter 3c503.c: Presently autoprobing (not recommended) for a single | 3c503: Presently autoprobing (not recommended) for a single c 3c503.c: No 3c503 card found (i/o = 0x0). | 3c503: No 3c503 card found (i/o = 0x0). 3c505.c: warning, using default DMA channel, | 3c505: warning, using default DMA channel, 3c505.c: module autoprobe not recommended, give io=xx.| 3c505: module autoprobe not recommended, give io=xx. 3c505.c: Failed to register card at 0x0. | 3c505: Failed to register card at 0x0. 3c515.c:v0.99t-ac 28-Oct-2002 [EMAIL PROTECTED] and others | 3c515:v0.99t-ac 28-Oct-2002 [EMAIL PROTECTED] and others tms380tr.c: v1.10 30/12/2002 by Christoph Goos, Adam Fritzler | tms380tr: v1.10 30/12/2002 by Christoph Goos, Adam Fritzler ac3200.c: No ac3200 card found (i/o = 0x0). | ac3200: No ac3200 card found (i/o = 0x0). drivers/input/tablet/acecad.c: v3.2:USB Acecad Flair tablet d | acecad: v3.2:USB Acecad Flair tablet driver drivers/usb/misc/adutux.c: adutux adutux (see www.ontrak.net) | adutux: adutux adutux (see www.ontrak.net) v0.0.13 drivers/usb/misc/adutux.c: adutux is an experimental driver. | adutux: adutux is an experimental driver. Use at your own ris drivers/input/tablet/aiptek.c: v2.3 (May 2, 2007): Bryan W. H | aiptek: v2.3 (May 2, 2007): Bryan W. Headley/Chris Atenasio/C drivers/input/tablet/aiptek.c: Aiptek HyperPen USB Tablet Dri | aiptek: Aiptek HyperPen USB Tablet Driver (Linux 2.6.x) drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for generic drivers/usb/serial/usb-serial.c: USB Serial Driver core | usb-serial: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for aircable drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver aircable drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver generic airo(): Probing for PCI adapters | airo: Probing for PCI adapters airo(): Finished probing for PCI adapters | airo: Finished probing for PCI adapters airo(): Probing for PCI adapters | airo: Probing for PCI adapters airo(): Finished probing for PCI adapters | airo: Finished probing for PCI adapters drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for generic drivers/usb/serial/usb-serial.c: USB Serial Driver core | usb-serial: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for airprime drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver airprime drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver generic drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for generic drivers/usb/serial/usb-serial.c: USB Serial Driver core | usb-serial: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registere | usb-serial: USB Serial support registered for ark3116 drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver ark3116 drivers/usb/serial/usb-serial.c: USB Serial deregistering dri | usb-serial: USB Serial deregistering driver generic drivers/input/misc/ati_remote.c: Registered USB driver ATI/X1 | ati_remote: Registered USB driver ATI/X10 RF USB Remote Contr atp.c:v1.09=ac 2002/10/01 Donald Becker [EMAIL PROTECTED]| atp:v1.09=ac 2002/10/01 Donald Becker [EMAIL PROTECTED] drivers/usb/serial/usb-serial.c: USB Serial support
Re: serial console _after_ boot ? - was: Redirect kernel console
>>>i was wondering how to make kernel messages appear on /dev/ttyS0
>>without a reboot, i.e. kernelparam "console=ttyS0"
>>
>>The solution is simple... the following piece of code is inside
>>opensuse-10.3/src/sysvinit-2.86-115.src.rpm#showconsole-1.08.tar.bz2#showconsole-1.08/blogd.c
>>
>>(void)ioctl(0, TIOCCONS, NULL); /* Undo any current map if any */
>>if (ioctl(pts, TIOCCONS, NULL) < 0)
>>error("can not set console device to %s: %s\n", ptsname,
>>strerror(errno));
>>
>>so I suppose that's it. Write up a new program that calls the ioctl
>>on a tty, and you should be done. IOW:
>
>TIOCCONS only works for pseudo terminals.
>
>Besides, it only redirects stuff you send to /dev/console. It
>doesn't change what devices printk() prints to. Currently there
>is no way to change that on a running kernel.
>
>Mike.
too bad, but thanks for the info.
___
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console _after_ boot ? - was: Redirect kernel console
> This errno is so out of place.
yes, that was stupid.
anyway:
# strace ./mytiocons
--snipp--
open("/dev/ttyS0", O_RDWR) = 3
ioctl(0, TIOCCONS) = -1 EBUSY (Device or resource busy)
ioctl(3, TIOCCONS) = -1 EBUSY (Device or resource busy)
--snipp--
man tty_ioctl is telling:
Redirecting console output
TIOCCONS void
Redirect output that would have gone to
/dev/console or /dev/tty0 to the given tty. If that was a pty master, send
it to the slave. Anybody can do this as long as the output was not redirected
yet. If it was redirected already EBUSY is returned, but root may stop
redirection by using this ioctl with fd pointing at /dev/console or /dev/tty0.
but it doesn`t seem to make any difference if i do that ioctl on /dev/console
or /dev/tty0 , because i`m getting EBUSY there, too
>
>
> On Jan 3 2008 15:39, [EMAIL PROTECTED] wrote:
> >fantastic, thanks!
> >
> >unfortunately..
> >
> >opensuse103:/home/roland/serialcons # ./mytioccons
> >ioctl: Device or resource busy
> >
> >but i`m not deep enough into programming to understand this.
> >
>
> >int main(void)
> >{
> >int fd = open("/dev/ttyS0", O_RDWR);
> >int errno;
>
> This errno is so out of place.
>
> >
> >ioctl(0, TIOCCONS, NULL);
> >
> >if (ioctl(fd, TIOCCONS, NULL) < 0)
> >printf("ioctl: %s\n", strerror(errno));
> >}
>
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071=0066
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console _after_ boot ? - was: Redirect kernel console
fantastic, thanks!
unfortunately..
opensuse103:/home/roland/serialcons # ./mytioccons
ioctl: Device or resource busy
but, it`s not userspace:
opensuse103:/home/roland # lsof |egrep "console|ttyS0"
opensuse103:/home/roland #
in tty_io.c -> ticoccons() there is
if (redirect) {
spin_unlock(_lock);
return -EBUSY;
}
but i`m not deep enough into programming to understand this.
---
mytioccons.c
#include
#include
#include
#include
#include
#include
#include
int main(void)
{
int fd = open("/dev/ttyS0", O_RDWR);
int errno;
ioctl(0, TIOCCONS, NULL);
if (ioctl(fd, TIOCCONS, NULL) < 0)
printf("ioctl: %s\n", strerror(errno));
}
---
> -Ursprüngliche Nachricht-
> Von: "Jan Engelhardt" <[EMAIL PROTECTED]>
> Gesendet: 03.01.08 14:28:45
> An: [EMAIL PROTECTED]
> CC: linux-kernel@vger.kernel.org
> Betreff: Re: serial console _after_ boot ? - was: Redirect kernel console
>
>
> On Jan 3 2008 13:43, [EMAIL PROTECTED] wrote:
> >
> >hi !
> >
> >i was wondering how to make kernel messages appear on /dev/ttyS0 without a
> >reboot, i.e. kernelparam "console=ttyS0"
>
> The solution is simple... the following piece of code is inside
> opensuse-10.3/src/sysvinit-2.86-115.src.rpm#showconsole-1.08.tar.bz2#showconsole-1.08/blogd.c
>
> (void)ioctl(0, TIOCCONS, NULL); /* Undo any current map if any */
> if (ioctl(pts, TIOCCONS, NULL) < 0)
> error("can not set console device to %s: %s\n", ptsname,
> strerror(errno));
>
> so I suppose that's it. Write up a new program that calls the ioctl
> on a tty, and you should be done. IOW:
>
> #include
> #include
> #include
> #include
>
> int main(void)
> {
> int fd = open("/dev/ttyS0", O_RDWR);
> ioctl(0, TIOCCONS, NULL);
> ioctl(fd, TIOCCONS, NULL);
> }
>
__
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://produkte.web.de/club/?mc=021131
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console _after_ boot ? - was: Redirect kernel console
hi ! i was wondering how to make kernel messages appear on /dev/ttyS0 without a reboot, i.e. kernelparam "console=ttyS0" after playing for a while with setconsole, setterm and klogconsole i didn`t find a way to make that happen. i can do "setconsole /dev/tty1 /dev/console" and see "test" on tty1 "setterm -msg on -msglevel 8 >/dev/console" (or >/dev/tty1), modprobe loop;rmmod loop - and i see the kernel message there i can do "setconsole /dev/ttyS0 /dev/console" and see "test" on ttyS0 BUT : "setterm -msg on -msglevel 8 >/dev/console" (or >/dev/ttyS0), modprobe loop;rmmod loop .. nothing! since i came across jan`s posting from 2005, which didn`t get a reply i think it`s not that stupid to ask again... any clue how to do that at runtime or what`s the issue here ? (see excerpts below) i can set regards roland List: linux-kernel Subject:Redirect kernel console From: Jan Engelhardt Date: 2005-08-13 12:48:22 Message-ID: Pine.LNX.4.61.0508131447220.4457 () yvahk01 ! tjqt ! qr [Download message RAW] Hi, there is a klogconsole utiltity that allows to change the console to which kernel messages are printed. However, is it possible to redirect to ttyS0 without a reboot? Jan Engelhardt --- >> Subject: Re: serial console _after_ boot ? >> > Setterm outputs the correct escape sequences to stdout. You can >> > configure another tty using 'setterm -msglevel 8 -msg on > /dev/ttyS0'. >> > I tested this on the standard kernel consoles (/dev/tty1-9), and it >> > worked. You obviously need root access to write the escape sequences to >> > the tty's. >> >> oh - yes, this works! but with tty1-9 only. >> not with ttyS0 :( > >.as the docs tell. > > Some options however (marked "virtual consoles only" below) do not > correspond to a terminfo(5) capability. > > -msg [on|off] (virtual consoles only) > Enables or disables the sending of kernel printk() messages to > the console. > > -msglevel 1-8 (virtual consoles only) > Sets the console logging level for kernel printk() messages. > All messages strictly more important than this > will be printed, so a logging level of 0 has the same effect > as -msg on and a logging level of 8 will print > all kernel messages. klogd(8) may be a more convenient > interface to the logging of kernel messages. > > > but i don`t have change_console. > > > searched the net and found that this eventually should be part of > > > sysvinit package. > > > but mine doesn`t provide that tool. > > > > > > found "setconsole" which looks like something similar, but "setconsole > > > /dev/ttyS0 < /dev/console" > > > doesn`t have any effect > > > > What distribution do you use? I have change_console on gentoo, yet I > > cannot find the tool on a debian etch. But that's a vserver, so it's > > probably not a reference. > > i have opensuse 10.3 _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console _after_ boot ? - was: Redirect kernel console
hi ! i was wondering how to make kernel messages appear on /dev/ttyS0 without a reboot, i.e. kernelparam console=ttyS0 after playing for a while with setconsole, setterm and klogconsole i didn`t find a way to make that happen. i can do setconsole /dev/tty1 /dev/console and then echo test /dev/console and see test on tty1 setterm -msg on -msglevel 8 /dev/console (or /dev/tty1), modprobe loop;rmmod loop - and i see the kernel message there i can do setconsole /dev/ttyS0 /dev/console and then echo test /dev/console and see test on ttyS0 BUT : setterm -msg on -msglevel 8 /dev/console (or /dev/ttyS0), modprobe loop;rmmod loop .. nothing! since i came across jan`s posting from 2005, which didn`t get a reply i think it`s not that stupid to ask again... any clue how to do that at runtime or what`s the issue here ? (see excerpts below) i can set regards roland List: linux-kernel Subject:Redirect kernel console From: Jan Engelhardt jengelh () linux01 ! gwdg ! de Date: 2005-08-13 12:48:22 Message-ID: Pine.LNX.4.61.0508131447220.4457 () yvahk01 ! tjqt ! qr [Download message RAW] Hi, there is a klogconsole utiltity that allows to change the console to which kernel messages are printed. However, is it possible to redirect to ttyS0 without a reboot? Jan Engelhardt --- Subject: Re: serial console _after_ boot ? Setterm outputs the correct escape sequences to stdout. You can configure another tty using 'setterm -msglevel 8 -msg on /dev/ttyS0'. I tested this on the standard kernel consoles (/dev/tty1-9), and it worked. You obviously need root access to write the escape sequences to the tty's. oh - yes, this works! but with tty1-9 only. not with ttyS0 :( .as the docs tell. Some options however (marked virtual consoles only below) do not correspond to a terminfo(5) capability. -msg [on|off] (virtual consoles only) Enables or disables the sending of kernel printk() messages to the console. -msglevel 1-8 (virtual consoles only) Sets the console logging level for kernel printk() messages. All messages strictly more important than this will be printed, so a logging level of 0 has the same effect as -msg on and a logging level of 8 will print all kernel messages. klogd(8) may be a more convenient interface to the logging of kernel messages. but i don`t have change_console. searched the net and found that this eventually should be part of sysvinit package. but mine doesn`t provide that tool. found setconsole which looks like something similar, but setconsole /dev/ttyS0 /dev/console doesn`t have any effect What distribution do you use? I have change_console on gentoo, yet I cannot find the tool on a debian etch. But that's a vserver, so it's probably not a reference. i have opensuse 10.3 _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console _after_ boot ? - was: Redirect kernel console
fantastic, thanks!
unfortunately..
opensuse103:/home/roland/serialcons # ./mytioccons
ioctl: Device or resource busy
but, it`s not userspace:
opensuse103:/home/roland # lsof |egrep console|ttyS0
opensuse103:/home/roland #
in tty_io.c - ticoccons() there is
if (redirect) {
spin_unlock(redirect_lock);
return -EBUSY;
}
but i`m not deep enough into programming to understand this.
---
mytioccons.c
#include sys/ioctl.h
#include sys/stat.h
#include sys/types.h
#include fcntl.h
#include libio.h
#include errno.h
#include stdio.h
int main(void)
{
int fd = open(/dev/ttyS0, O_RDWR);
int errno;
ioctl(0, TIOCCONS, NULL);
if (ioctl(fd, TIOCCONS, NULL) 0)
printf(ioctl: %s\n, strerror(errno));
}
---
-Ursprüngliche Nachricht-
Von: Jan Engelhardt [EMAIL PROTECTED]
Gesendet: 03.01.08 14:28:45
An: [EMAIL PROTECTED]
CC: linux-kernel@vger.kernel.org
Betreff: Re: serial console _after_ boot ? - was: Redirect kernel console
On Jan 3 2008 13:43, [EMAIL PROTECTED] wrote:
hi !
i was wondering how to make kernel messages appear on /dev/ttyS0 without a
reboot, i.e. kernelparam console=ttyS0
The solution is simple... the following piece of code is inside
opensuse-10.3/src/sysvinit-2.86-115.src.rpm#showconsole-1.08.tar.bz2#showconsole-1.08/blogd.c
(void)ioctl(0, TIOCCONS, NULL); /* Undo any current map if any */
if (ioctl(pts, TIOCCONS, NULL) 0)
error(can not set console device to %s: %s\n, ptsname,
strerror(errno));
so I suppose that's it. Write up a new program that calls the ioctl
on a tty, and you should be done. IOW:
#include sys/ioctl.h
#include sys/stat.h
#include sys/types.h
#include fcntl.h
int main(void)
{
int fd = open(/dev/ttyS0, O_RDWR);
ioctl(0, TIOCCONS, NULL);
ioctl(fd, TIOCCONS, NULL);
}
__
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://produkte.web.de/club/?mc=021131
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console _after_ boot ? - was: Redirect kernel console
This errno is so out of place.
yes, that was stupid.
anyway:
# strace ./mytiocons
--snipp--
open(/dev/ttyS0, O_RDWR) = 3
ioctl(0, TIOCCONS) = -1 EBUSY (Device or resource busy)
ioctl(3, TIOCCONS) = -1 EBUSY (Device or resource busy)
--snipp--
man tty_ioctl is telling:
Redirecting console output
TIOCCONS void
Redirect output that would have gone to
/dev/console or /dev/tty0 to the given tty. If that was a pty master, send
it to the slave. Anybody can do this as long as the output was not redirected
yet. If it was redirected already EBUSY is returned, but root may stop
redirection by using this ioctl with fd pointing at /dev/console or /dev/tty0.
but it doesn`t seem to make any difference if i do that ioctl on /dev/console
or /dev/tty0 , because i`m getting EBUSY there, too
On Jan 3 2008 15:39, [EMAIL PROTECTED] wrote:
fantastic, thanks!
unfortunately..
opensuse103:/home/roland/serialcons # ./mytioccons
ioctl: Device or resource busy
but i`m not deep enough into programming to understand this.
int main(void)
{
int fd = open(/dev/ttyS0, O_RDWR);
int errno;
This errno is so out of place.
ioctl(0, TIOCCONS, NULL);
if (ioctl(fd, TIOCCONS, NULL) 0)
printf(ioctl: %s\n, strerror(errno));
}
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071distributionid=0066
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console _after_ boot ? - was: Redirect kernel console
i was wondering how to make kernel messages appear on /dev/ttyS0 without a reboot, i.e. kernelparam console=ttyS0 The solution is simple... the following piece of code is inside opensuse-10.3/src/sysvinit-2.86-115.src.rpm#showconsole-1.08.tar.bz2#showconsole-1.08/blogd.c (void)ioctl(0, TIOCCONS, NULL); /* Undo any current map if any */ if (ioctl(pts, TIOCCONS, NULL) 0) error(can not set console device to %s: %s\n, ptsname, strerror(errno)); so I suppose that's it. Write up a new program that calls the ioctl on a tty, and you should be done. IOW: TIOCCONS only works for pseudo terminals. Besides, it only redirects stuff you send to /dev/console. It doesn't change what devices printk() prints to. Currently there is no way to change that on a running kernel. Mike. too bad, but thanks for the info. ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] crash - module radio-sf16fmr2 and esp interfere
> > same with radio-sf16fmr2 and esp > > > > after repeatedly modrpobe/modprobe -r radio-sf16fmr2, i can hang my > > system when loading esp afterwards > > > > before loading esp, doing a "cat /proc/ioport" segfaults > > > > this is with 2.6.24rc6 and also with 2.6.22 > > > > i have found these issues by running some (probably sick :D ) module > > load/unload test across all modules > > > > Hi, > Please provide more kernel crash info, as listed in the > REPORTING-BUGS file in the top-level directory of the kernel > source tree. thanks for the pointer, i will mind that in the future. __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] crash - module radio-sf16fmr2 and esp interfere
same with radio-sf16fmr2 and esp after repeatedly modrpobe/modprobe -r radio-sf16fmr2, i can hang my system when loading esp afterwards before loading esp, doing a cat /proc/ioport segfaults this is with 2.6.24rc6 and also with 2.6.22 i have found these issues by running some (probably sick :D ) module load/unload test across all modules Hi, Please provide more kernel crash info, as listed in the REPORTING-BUGS file in the top-level directory of the kernel source tree. thanks for the pointer, i will mind that in the future. __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] crash - module radio-sf16fmr2 and esp interfere
same with radio-sf16fmr2 and esp after repeatedly modrpobe/modprobe -r radio-sf16fmr2, i can hang my system when loading esp afterwards before loading esp, doing a "cat /proc/ioport" segfaults this is with 2.6.24rc6 and also with 2.6.22 i have found these issues by running some (probably sick :D ) module load/unload test across all modules > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] > Gesendet: 01.01.08 21:46:30 > An: linux-kernel@vger.kernel.org > Betreff: Re: [BUG] crash - module l440gx buggy ? interfere > > same/similar behaviour with > > l440gx and container > l440gx and acpiphp > > after load of l440gx, container and acpiphp modules do also hang my system on > load/unload. > > maybe l440gx leaving the system in some weird state after probe ? > > > > -Ursprüngliche Nachricht- > > Von: <[EMAIL PROTECTED]> > > Gesendet: 01.01.08 20:57:08 > > An: linux-kernel@vger.kernel.org > > Betreff: [BUG] crash - modules l440gx and parport_pc interfere > > > > > > there seems some weird interference between l440gx and parport_pc modules > > > > i can reproduceable crash my box by either: > > > > modprobe parport_pc;modprobe l440gx;rmmod parport_pc > > > > or > > > > modprobe l440gx; modprobe parport_pc;rmmod parport_pc > > > > this happens on 2.6.24rc6 and also older kernel (2.6.22) > > > > nothing in dmesg - just > > >JEDEC: Found no L440GX BIOS device at location zero > > >JEDEC probe on BIOS chip failed. Using ROM > > > > because i haven`t appropriate hardware. > > > > don`t know if this is a bug in parport_pc or l440gx but maybe its worth > > reporting. > > > > regards > > roland > > ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] crash - module l440gx buggy ? interfere
same/similar behaviour with l440gx and container l440gx and acpiphp after load of l440gx, container and acpiphp modules do also hang my system on load/unload. maybe l440gx leaving the system in some weird state after probe ? > -Ursprüngliche Nachricht- > Von: <[EMAIL PROTECTED]> > Gesendet: 01.01.08 20:57:08 > An: linux-kernel@vger.kernel.org > Betreff: [BUG] crash - modules l440gx and parport_pc interfere > > there seems some weird interference between l440gx and parport_pc modules > > i can reproduceable crash my box by either: > > modprobe parport_pc;modprobe l440gx;rmmod parport_pc > > or > > modprobe l440gx; modprobe parport_pc;rmmod parport_pc > > this happens on 2.6.24rc6 and also older kernel (2.6.22) > > nothing in dmesg - just > >JEDEC: Found no L440GX BIOS device at location zero > >JEDEC probe on BIOS chip failed. Using ROM > > because i haven`t appropriate hardware. > > don`t know if this is a bug in parport_pc or l440gx but maybe its worth > reporting. > > regards > roland ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] crash - modules l440gx and parport_pc interfere
there seems some weird interference between l440gx and parport_pc modules i can reproduceable crash my box by either: modprobe parport_pc;modprobe l440gx;rmmod parport_pc or modprobe l440gx; modprobe parport_pc;rmmod parport_pc this happens on 2.6.24rc6 and also older kernel (2.6.22) nothing in dmesg - just >JEDEC: Found no L440GX BIOS device at location zero >JEDEC probe on BIOS chip failed. Using ROM because i haven`t appropriate hardware. don`t know if this is a bug in parport_pc or l440gx but maybe its worth reporting. regards roland ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] crash - modules l440gx and parport_pc interfere
there seems some weird interference between l440gx and parport_pc modules i can reproduceable crash my box by either: modprobe parport_pc;modprobe l440gx;rmmod parport_pc or modprobe l440gx; modprobe parport_pc;rmmod parport_pc this happens on 2.6.24rc6 and also older kernel (2.6.22) nothing in dmesg - just JEDEC: Found no L440GX BIOS device at location zero JEDEC probe on BIOS chip failed. Using ROM because i haven`t appropriate hardware. don`t know if this is a bug in parport_pc or l440gx but maybe its worth reporting. regards roland ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] crash - module l440gx buggy ? interfere
same/similar behaviour with l440gx and container l440gx and acpiphp after load of l440gx, container and acpiphp modules do also hang my system on load/unload. maybe l440gx leaving the system in some weird state after probe ? -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] Gesendet: 01.01.08 20:57:08 An: linux-kernel@vger.kernel.org Betreff: [BUG] crash - modules l440gx and parport_pc interfere there seems some weird interference between l440gx and parport_pc modules i can reproduceable crash my box by either: modprobe parport_pc;modprobe l440gx;rmmod parport_pc or modprobe l440gx; modprobe parport_pc;rmmod parport_pc this happens on 2.6.24rc6 and also older kernel (2.6.22) nothing in dmesg - just JEDEC: Found no L440GX BIOS device at location zero JEDEC probe on BIOS chip failed. Using ROM because i haven`t appropriate hardware. don`t know if this is a bug in parport_pc or l440gx but maybe its worth reporting. regards roland ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] crash - module radio-sf16fmr2 and esp interfere
same with radio-sf16fmr2 and esp after repeatedly modrpobe/modprobe -r radio-sf16fmr2, i can hang my system when loading esp afterwards before loading esp, doing a cat /proc/ioport segfaults this is with 2.6.24rc6 and also with 2.6.22 i have found these issues by running some (probably sick :D ) module load/unload test across all modules -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] Gesendet: 01.01.08 21:46:30 An: linux-kernel@vger.kernel.org Betreff: Re: [BUG] crash - module l440gx buggy ? interfere same/similar behaviour with l440gx and container l440gx and acpiphp after load of l440gx, container and acpiphp modules do also hang my system on load/unload. maybe l440gx leaving the system in some weird state after probe ? -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] Gesendet: 01.01.08 20:57:08 An: linux-kernel@vger.kernel.org Betreff: [BUG] crash - modules l440gx and parport_pc interfere there seems some weird interference between l440gx and parport_pc modules i can reproduceable crash my box by either: modprobe parport_pc;modprobe l440gx;rmmod parport_pc or modprobe l440gx; modprobe parport_pc;rmmod parport_pc this happens on 2.6.24rc6 and also older kernel (2.6.22) nothing in dmesg - just JEDEC: Found no L440GX BIOS device at location zero JEDEC probe on BIOS chip failed. Using ROM because i haven`t appropriate hardware. don`t know if this is a bug in parport_pc or l440gx but maybe its worth reporting. regards roland ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Force UNIX domain sockets to be built in
when i had that module modular and added to the initrd, udev didn`t work, though. same error message: udevd[1226]: init_udev_socket: error getting socket: Address family not supported by protocol not sure if i did a mistake here anyway, this message is not obvious to the end user. i like the kernel being modular, but i also like it if things "just work" - and with "allmodconfig", modular UNIX domain sockets seem to create hassle. (see http://forums.gentoo.org/viewtopic-t-476363-highlight-.html or http://forums.gentoo.org/viewtopic-t-463793-highlight-.html ) so, if this patch is being rejected, maybe it would be useful if udev would give a proper hint, if it`s missing this kernel feature. btw, udev documentation telling this: - The kernel must have sysfs, unix domain sockets and networking enabled. (unix domain sockets (CONFIG_UNIX) as a loadable kernel module may work, but it is completely silly - don't complain if anything goes wrong.) furthermore, if this needs to be modular, then i`d please have tcp/ip networking modular, too. :) regards roland ps: not being a skilled programmer, so this is mostly an admins/users perspective. > > From: Bodo Eggert <[EMAIL PROTECTED]> > Date: Mon, 31 Dec 2007 13:09:43 +0100 (CET) > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in > > on normal systems. This is especially true since udev needs these sockets > > and fails to run if UNIX=m. > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > People who use udev can make sure they have it built into their kernel > if they have such a dependency. > > Not everyone uses udev, and therefore needs AF_UNIX non-modular. > > I keep seeing this crap patch get submitted and I'm going to keep > dropping it because it's bogus. > > It seems to stem from some filesystem interface or whatever that the > VFS folks don't want to export or one they want to now stop exporting. > > But that is a really cruddy reason to want to force AF_UNIX to not > be allowed to be modular, and the udev thing just makes it more of a > joke rather than a good technical reason. > ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Force UNIX domain sockets to be built in
when i had that module modular and added to the initrd, udev didn`t work, though. same error message: udevd[1226]: init_udev_socket: error getting socket: Address family not supported by protocol not sure if i did a mistake here anyway, this message is not obvious to the end user. i like the kernel being modular, but i also like it if things just work - and with allmodconfig, modular UNIX domain sockets seem to create hassle. (see http://forums.gentoo.org/viewtopic-t-476363-highlight-.html or http://forums.gentoo.org/viewtopic-t-463793-highlight-.html ) so, if this patch is being rejected, maybe it would be useful if udev would give a proper hint, if it`s missing this kernel feature. btw, udev documentation telling this: - The kernel must have sysfs, unix domain sockets and networking enabled. (unix domain sockets (CONFIG_UNIX) as a loadable kernel module may work, but it is completely silly - don't complain if anything goes wrong.) furthermore, if this needs to be modular, then i`d please have tcp/ip networking modular, too. :) regards roland ps: not being a skilled programmer, so this is mostly an admins/users perspective. From: Bodo Eggert [EMAIL PROTECTED] Date: Mon, 31 Dec 2007 13:09:43 +0100 (CET) As suggested by Adrian Bunk, UNIX domain sockets should always be built in on normal systems. This is especially true since udev needs these sockets and fails to run if UNIX=m. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] People who use udev can make sure they have it built into their kernel if they have such a dependency. Not everyone uses udev, and therefore needs AF_UNIX non-modular. I keep seeing this crap patch get submitted and I'm going to keep dropping it because it's bogus. It seems to stem from some filesystem interface or whatever that the VFS folks don't want to export or one they want to now stop exporting. But that is a really cruddy reason to want to force AF_UNIX to not be allowed to be modular, and the udev thing just makes it more of a joke rather than a good technical reason. ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.24rc6 allmodconfig - unload capidrv fails
rmmod capidrv never returns this is 2.6.24-rc6 with allmodconfig gcc version 4.2.1 (SUSE Linux) also see https://bugzilla.novell.com/show_bug.cgi?id=350850 [ 1807.666763] capidrv: Rev 1.1.2.2: loaded [ 1810.803450] capidrv: Rev 1.1.2.2 : unloaded [ 1810.808417] BUG: unable to handle kernel NULL pointer dereference at virtual address 0009 [ 1810.808446] printing eip: c020afca *pde = [ 1810.809301] Oops: [#1] SMP [ 1810.810225] Modules linked in: capidrv kernelcapi isdn slhc iptable_filter ip_tables edd ip6table_filter ip6_tables x_tables ipv6 af_packet microcode firmware_class fuse loop dm_mod 8250_pnp ide_cd cdrom pata_acpi ata_piix ahci parport_pc floppy pcnet32 8250 parport serial_core ata_generic rtc_cmos rtc_core mii rtc_lib libata pcspkr i2c_piix4 i2c_core piix generic container ac ide_core intel_agp power_supply agpgart button thermal shpchp processor pci_hotplug mousedev evdev sg ext3 jbd mbcache sd_mod mptspi mptscsih mptbase scsi_transport_spi scsi_mod [ 1810.810402] [ 1810.810471] Pid: 4500, comm: kstopmachine Not tainted (2.6.24-rc6allmodconfig #3) [ 1810.810488] EIP: 0060:[] EFLAGS: 00010092 CPU: 0 [ 1810.810609] EIP is at list_del+0xa/0x61 [ 1810.810716] EAX: e0ae8704 EBX: 0009 ECX: EDX: df686e10 [ 1810.810808] ESI: de8f4ef0 EDI: EBP: deb57fb4 ESP: deb57fa4 [ 1810.810890] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 1810.812131] Process kstopmachine (pid: 4500, ti=deb57000 task=df686e10 task.ti=deb57000) [ 1810.812156] Stack: c03f50ac 0046 0008 deb57fbc c0153506 deb57fd0 c015fb58 [ 1810.812412]de8f4ef0 c015fa9c deb57fe0 c013fe7e c013fe43 [ 1810.812424]c0108d77 de8f4e6c [ 1810.812444] Call Trace: [ 1810.812485] [] show_trace_log_lvl+0x1a/0x2f [ 1810.812569] [] show_stack_log_lvl+0x9b/0xa3 [ 1810.812577] [] show_registers+0xa7/0x179 [ 1810.812584] [] die+0x13a/0x225 [ 1810.812589] [] do_page_fault+0x554/0x632 [ 1810.812616] [] error_code+0x72/0x78 [ 1810.812624] [] __unlink_module+0xb/0xf [ 1810.812635] [] do_stop+0xbc/0x110 [ 1810.812643] [] kthread+0x3b/0x61 [ 1810.812649] [] kernel_thread_helper+0x7/0x10 [ 1810.812669] === [ 1810.812680] Code: 00 00 8b 53 10 8d 4b 0c 8d 46 0c e8 72 00 00 00 89 f8 e8 87 fe ff ff 83 c4 10 5b 5e 5f 5d c3 90 90 55 89 e5 53 83 ec 0c 8b 58 04 <8b> 0b 39 c1 74 18 89 4c 24 08 89 44 24 04 c7 04 24 1a 1d 39 c0 [ 1810.812691] EIP: [] list_del+0xa/0x61 SS:ESP 0068:deb57fa4 [ 1810.812700] ---[ end trace 25d0c1bb6d183e81 ]--- __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
allmodconfig: udev won`t start due to CONFIG_UNIX=m
Hi ! i build a kernel with allmodconfig and didn`t get my system to boot with that. after some investigation i found that it was due to udev: udevd[1226]: init_udev_socket: error getting socket: Address family not supported by protocol this was missing support UNIX DOMAIN SOCKETS at boot time. easy - so i added unix.ko to my initrd. but that didn`t make a difference. Still same error with udev. seems, there are others who stepped into this trap and someone telling, unix domain sockets cannot be modular https://forums.gentoo.org/viewtopic-t-476363-highlight-.html https://forums.gentoo.org/viewtopic-t-463793-highlight-.html since we have 1206 options set to "Y" anyway, would it make sense to remove module support for Unix Domain Sockets ? opensuse103:/home/kernel/linux-2.6.23 # cat .config.allmodconfig |grep "=y" |wc -l 1206 opensuse103:/home/kernel/linux-2.6.23 # cat .config.allmodconfig |grep "=m" |wc -l 2098 i also came across this one: http://readlist.com/lists/vger.kernel.org/linux-kernel/41/205717.html __ XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club! Jetzt testen! http://produkte.web.de/club/?mc=021130 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: 2.6.24-rc5: mtd: PNC-2000 oops
while doing some systematical driver load/unload testing i have also come across this one. searched lkml and found/tried this patch - seems to work fine, at least driver now behaves as expected: insmod: error inserting 'pnc2000.ko': -1 No such device or address if it really _works_ is another story, but how can we know ? have searched the net a while for this hardware, but didn`t find _any_ reference that this hardware either exists or existed at all, so it looks that this hardware is very ancient or being used by japanese secret service, only !? :) > The driver is broken for a long time. I ever ping the writer > [EMAIL PROTECTED] (seems a company's email address), but got no > response. i have found email @crossnet from two people who seem to be involved in software development more or less. have sent them a mail and asked if they know anything about this or could re-establish a contact to the author. anyway, i vote for the patch being merged to avoid people investigate into this oops or complain here again. if there is fear, that this breaks the driver even more, what about putting some message into the driver initialization ? >>> PNC-2000 seems to be very ancient/rare hardware and the driver appears >>> unmaintained >>> for a while. Due to missing testing capabilities, there`s no guarantee, >>> that this driver still >>> works. If you own such hardware or if the driver doesn`t work for you, >>> please report to >>> linux-kernel@vger.kernel.org regards roland List: linux-kernel Subject:[PATCH]: 2.6.24-rc5: mtd: PNC-2000 oops From: "Luiz Fernando N. Capitulino" Date: 2007-12-14 16:00:26 Message-ID: 20071214140026.621c9007 () mandriva ! com ! br [Download message RAW] Em Fri, 14 Dec 2007 10:06:20 +0800 "Dave Young" <[EMAIL PROTECTED]> escreveu: > On Dec 14, 2007 1:04 AM, Luiz Fernando N. Capitulino > <[EMAIL PROTECTED]> wrote: > > > > Hi there, > > > > If I run: > > > > # modprobe pnc2000 > > > > In a machine w/o mtd hardware, I get the following oops: > > > > Photron PNC-2000 flash mapping: 40 at bf00 > > BUG: unable to handle kernel paging request at virtual address bf00 > > printing eip: e0bfe05b *pde = > > Oops: 0002 [#1] > > Modules linked in: cfi_probe gen_probe pnc2000 mtd chipreg map_funcs nfsd > > lockd \ > > nfs_acl auth_rpcgss sunrpc exportfs af_packet snd_seq_dummy snd_seq_oss \ > > snd_seq_midi_event snd_seq snd_pcm_oss ipv6 snd_mixer_oss binfmt_misc loop \ > > dm_mirror dm_mod sata_via libata scsi_mod floppy cpufreq_ondemand \ > > cpufreq_conservative cpufreq_powersave freq_table firewire_ohci > > firewire_core \ > > crc_itu_t snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_timer \ > > snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device i2c_viapro > > ehci_hcd snd \ > > uhci_hcd i2c_core soundcore 8139cp ide_cd cdrom ohci1394 usbcore ieee1394 > > via_agp \ > > 8139too mii agpgart shpchp pci_hotplug evdev ext3 jbd ide_disk ide_generic \ > > via82cxxx ide_core > > > > Pid: 4067, comm: modprobe Not tainted (2.6.24-0.rc5.1mdv #1) > > EIP: 0060:[] EFLAGS: 00010286 CPU: 0 > > EIP is at simple_map_write+0x2a/0x34 [map_funcs] > > EAX: 0004 EBX: e0c3f5d0 ECX: bf00 EDX: 00f000f0 > > ESI: e0c3f5d0 EDI: 0002 EBP: dc913dbc ESP: dc913db8 > > DS: 007b ES: 007b FS: GS: 0033 SS: 0068 > > Process modprobe (pid: 4067, ti=dc912000 task=df0409f0 task.ti=dc912000) > > Stack: 0004 dc913e18 e0cc1277 dc913e30 c012b89b 0001 > > 0002 > > c04a2b7c 0008 c043cde4 c0357ccb dc913e1c > > dc913e1c 0204 e0c00a54 e0cc119d 0002 0002 > > Call Trace: > > [] show_trace_log_lvl+0x1a/0x2f > > [] show_stack_log_lvl+0x9b/0xa3 > > [] show_registers+0xa6/0x177 > > [] die+0x102/0x1ee > > [] do_page_fault+0x561/0x63f > > [] error_code+0x6a/0x70 > > [] cfi_probe_chip+0xda/0x9c7 [cfi_probe] > > [] mtd_do_chip_probe+0x77/0x2d4 [gen_probe] > > [] cfi_probe+0xd/0xf [cfi_probe] > > [] do_map_probe+0x3d/0x5a [chipreg] > > [] init_pnc2000+0x3b/0x68 [pnc2000] > > [] sys_init_module+0x12c6/0x1394 > > [] sysenter_past_esp+0x6b/0xc9 > > === > > Code: c3 55 89 e5 53 89 c3 8b 40 18 83 f8 01 75 07 03 4b 10 88 11 eb 17 83 > > f8 02 \ > > 75 08 03 4b 10 66 89 11 eb 0a 83 f8 04 75 05 03 4b 10 <89> 11 f0 83 04 24 > > 00 5b \ > > 5d c3 55 89 e5 57 89 d7 8b 55 08 56 89 > > EIP: [] simple_map_write+0x2a/0x34 [map_funcs] SS:ESP > > 0068:dc913db8 > > > > -- > > This issue has been reported several times. Oh. > The driver is broken for a long time. I ever ping the writer > [EMAIL PROTECTED] (seems a company's email address), but got no > response. > > So how about kill (or disable ?) this driver until it is fixed? Well, looks like there's an ioremap() call missing there. The following patch does what every driver of that kind does. It fixes the load OOPS for me but we need someone with the hardware to test whether it works (or
Re: [PATCH]: 2.6.24-rc5: mtd: PNC-2000 oops
while doing some systematical driver load/unload testing i have also come across this one. searched lkml and found/tried this patch - seems to work fine, at least driver now behaves as expected: insmod: error inserting 'pnc2000.ko': -1 No such device or address if it really _works_ is another story, but how can we know ? have searched the net a while for this hardware, but didn`t find _any_ reference that this hardware either exists or existed at all, so it looks that this hardware is very ancient or being used by japanese secret service, only !? :) The driver is broken for a long time. I ever ping the writer [EMAIL PROTECTED] (seems a company's email address), but got no response. i have found email @crossnet from two people who seem to be involved in software development more or less. have sent them a mail and asked if they know anything about this or could re-establish a contact to the author. anyway, i vote for the patch being merged to avoid people investigate into this oops or complain here again. if there is fear, that this breaks the driver even more, what about putting some message into the driver initialization ? PNC-2000 seems to be very ancient/rare hardware and the driver appears unmaintained for a while. Due to missing testing capabilities, there`s no guarantee, that this driver still works. If you own such hardware or if the driver doesn`t work for you, please report to linux-kernel@vger.kernel.org regards roland List: linux-kernel Subject:[PATCH]: 2.6.24-rc5: mtd: PNC-2000 oops From: Luiz Fernando N. Capitulino lcapitulino () mandriva ! com ! br Date: 2007-12-14 16:00:26 Message-ID: 20071214140026.621c9007 () mandriva ! com ! br [Download message RAW] Em Fri, 14 Dec 2007 10:06:20 +0800 Dave Young [EMAIL PROTECTED] escreveu: On Dec 14, 2007 1:04 AM, Luiz Fernando N. Capitulino [EMAIL PROTECTED] wrote: Hi there, If I run: # modprobe pnc2000 In a machine w/o mtd hardware, I get the following oops: Photron PNC-2000 flash mapping: 40 at bf00 BUG: unable to handle kernel paging request at virtual address bf00 printing eip: e0bfe05b *pde = Oops: 0002 [#1] Modules linked in: cfi_probe gen_probe pnc2000 mtd chipreg map_funcs nfsd lockd \ nfs_acl auth_rpcgss sunrpc exportfs af_packet snd_seq_dummy snd_seq_oss \ snd_seq_midi_event snd_seq snd_pcm_oss ipv6 snd_mixer_oss binfmt_misc loop \ dm_mirror dm_mod sata_via libata scsi_mod floppy cpufreq_ondemand \ cpufreq_conservative cpufreq_powersave freq_table firewire_ohci firewire_core \ crc_itu_t snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_timer \ snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device i2c_viapro ehci_hcd snd \ uhci_hcd i2c_core soundcore 8139cp ide_cd cdrom ohci1394 usbcore ieee1394 via_agp \ 8139too mii agpgart shpchp pci_hotplug evdev ext3 jbd ide_disk ide_generic \ via82cxxx ide_core Pid: 4067, comm: modprobe Not tainted (2.6.24-0.rc5.1mdv #1) EIP: 0060:[e0bfe05b] EFLAGS: 00010286 CPU: 0 EIP is at simple_map_write+0x2a/0x34 [map_funcs] EAX: 0004 EBX: e0c3f5d0 ECX: bf00 EDX: 00f000f0 ESI: e0c3f5d0 EDI: 0002 EBP: dc913dbc ESP: dc913db8 DS: 007b ES: 007b FS: GS: 0033 SS: 0068 Process modprobe (pid: 4067, ti=dc912000 task=df0409f0 task.ti=dc912000) Stack: 0004 dc913e18 e0cc1277 dc913e30 c012b89b 0001 0002 c04a2b7c 0008 c043cde4 c0357ccb dc913e1c dc913e1c 0204 e0c00a54 e0cc119d 0002 0002 Call Trace: [c01054f2] show_trace_log_lvl+0x1a/0x2f [c01055a2] show_stack_log_lvl+0x9b/0xa3 [c0105650] show_registers+0xa6/0x177 [c0105823] die+0x102/0x1ee [c02cb4d2] do_page_fault+0x561/0x63f [c02c9d1a] error_code+0x6a/0x70 [e0cc1277] cfi_probe_chip+0xda/0x9c7 [cfi_probe] [e0c43123] mtd_do_chip_probe+0x77/0x2d4 [gen_probe] [e0cc119b] cfi_probe+0xd/0xf [cfi_probe] [e0c00142] do_map_probe+0x3d/0x5a [chipreg] [e0c4103b] init_pnc2000+0x3b/0x68 [pnc2000] [c0140d10] sys_init_module+0x12c6/0x1394 [c0103e42] sysenter_past_esp+0x6b/0xc9 === Code: c3 55 89 e5 53 89 c3 8b 40 18 83 f8 01 75 07 03 4b 10 88 11 eb 17 83 f8 02 \ 75 08 03 4b 10 66 89 11 eb 0a 83 f8 04 75 05 03 4b 10 89 11 f0 83 04 24 00 5b \ 5d c3 55 89 e5 57 89 d7 8b 55 08 56 89 EIP: [e0bfe05b] simple_map_write+0x2a/0x34 [map_funcs] SS:ESP 0068:dc913db8 -- This issue has been reported several times. Oh. The driver is broken for a long time. I ever ping the writer [EMAIL PROTECTED] (seems a company's email address), but got no response. So how about kill (or disable ?) this driver until it is fixed? Well, looks like there's an ioremap() call missing there. The following patch does what every driver of that kind does. It fixes the load OOPS for me but we need someone with the hardware to test whether it works (or some mtd person to
allmodconfig: udev won`t start due to CONFIG_UNIX=m
Hi ! i build a kernel with allmodconfig and didn`t get my system to boot with that. after some investigation i found that it was due to udev: udevd[1226]: init_udev_socket: error getting socket: Address family not supported by protocol this was missing support UNIX DOMAIN SOCKETS at boot time. easy - so i added unix.ko to my initrd. but that didn`t make a difference. Still same error with udev. seems, there are others who stepped into this trap and someone telling, unix domain sockets cannot be modular https://forums.gentoo.org/viewtopic-t-476363-highlight-.html https://forums.gentoo.org/viewtopic-t-463793-highlight-.html since we have 1206 options set to Y anyway, would it make sense to remove module support for Unix Domain Sockets ? opensuse103:/home/kernel/linux-2.6.23 # cat .config.allmodconfig |grep =y |wc -l 1206 opensuse103:/home/kernel/linux-2.6.23 # cat .config.allmodconfig |grep =m |wc -l 2098 i also came across this one: http://readlist.com/lists/vger.kernel.org/linux-kernel/41/205717.html __ XXL-Speicher, PC-Virenschutz, Spartarife mehr: Nur im WEB.DE Club! Jetzt testen! http://produkte.web.de/club/?mc=021130 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.24rc6 allmodconfig - unload capidrv fails
rmmod capidrv never returns this is 2.6.24-rc6 with allmodconfig gcc version 4.2.1 (SUSE Linux) also see https://bugzilla.novell.com/show_bug.cgi?id=350850 [ 1807.666763] capidrv: Rev 1.1.2.2: loaded [ 1810.803450] capidrv: Rev 1.1.2.2 : unloaded [ 1810.808417] BUG: unable to handle kernel NULL pointer dereference at virtual address 0009 [ 1810.808446] printing eip: c020afca *pde = [ 1810.809301] Oops: [#1] SMP [ 1810.810225] Modules linked in: capidrv kernelcapi isdn slhc iptable_filter ip_tables edd ip6table_filter ip6_tables x_tables ipv6 af_packet microcode firmware_class fuse loop dm_mod 8250_pnp ide_cd cdrom pata_acpi ata_piix ahci parport_pc floppy pcnet32 8250 parport serial_core ata_generic rtc_cmos rtc_core mii rtc_lib libata pcspkr i2c_piix4 i2c_core piix generic container ac ide_core intel_agp power_supply agpgart button thermal shpchp processor pci_hotplug mousedev evdev sg ext3 jbd mbcache sd_mod mptspi mptscsih mptbase scsi_transport_spi scsi_mod [ 1810.810402] [ 1810.810471] Pid: 4500, comm: kstopmachine Not tainted (2.6.24-rc6allmodconfig #3) [ 1810.810488] EIP: 0060:[c020afca] EFLAGS: 00010092 CPU: 0 [ 1810.810609] EIP is at list_del+0xa/0x61 [ 1810.810716] EAX: e0ae8704 EBX: 0009 ECX: EDX: df686e10 [ 1810.810808] ESI: de8f4ef0 EDI: EBP: deb57fb4 ESP: deb57fa4 [ 1810.810890] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 1810.812131] Process kstopmachine (pid: 4500, ti=deb57000 task=df686e10 task.ti=deb57000) [ 1810.812156] Stack: c03f50ac 0046 0008 deb57fbc c0153506 deb57fd0 c015fb58 [ 1810.812412]de8f4ef0 c015fa9c deb57fe0 c013fe7e c013fe43 [ 1810.812424]c0108d77 de8f4e6c [ 1810.812444] Call Trace: [ 1810.812485] [c01091cd] show_trace_log_lvl+0x1a/0x2f [ 1810.812569] [c010927d] show_stack_log_lvl+0x9b/0xa3 [ 1810.812577] [c010932c] show_registers+0xa7/0x179 [ 1810.812584] [c0109538] die+0x13a/0x225 [ 1810.812589] [c02eb811] do_page_fault+0x554/0x632 [ 1810.812616] [c02e9e52] error_code+0x72/0x78 [ 1810.812624] [c0153506] __unlink_module+0xb/0xf [ 1810.812635] [c015fb58] do_stop+0xbc/0x110 [ 1810.812643] [c013fe7e] kthread+0x3b/0x61 [ 1810.812649] [c0108d77] kernel_thread_helper+0x7/0x10 [ 1810.812669] === [ 1810.812680] Code: 00 00 8b 53 10 8d 4b 0c 8d 46 0c e8 72 00 00 00 89 f8 e8 87 fe ff ff 83 c4 10 5b 5e 5f 5d c3 90 90 55 89 e5 53 83 ec 0c 8b 58 04 8b 0b 39 c1 74 18 89 4c 24 08 89 44 24 04 c7 04 24 1a 1d 39 c0 [ 1810.812691] EIP: [c020afca] list_del+0xa/0x61 SS:ESP 0068:deb57fa4 [ 1810.812700] ---[ end trace 25d0c1bb6d183e81 ]--- __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: modules_install regression ? - depmod
> Erm... same system here - > > $ gzip -cd /proc/config.gz | grep DEBUG_INFO > # CONFIG_DEBUG_INFO is not set > > I think you managed to snafu something during building. mhh - i have kernel-default-2.6.22.13-0.3 kernel (didn`t touch that since online update) and this has CONFIG_DEBUG_INFO=y wondering about that, i installed shipping kernel (kernel-default-2.6.22.5-31 from http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/i586/ ) but: opensuse103:~ # uname -a Linux opensuse103 2.6.22.5-31-default #1 SMP 2007/09/21 22:29:00 UTC i686 i686 i386 GNU/Linux opensuse103:~ # zcat /proc/config.gz |grep DEBUG_INFO CONFIG_DEBUG_INFO=y so i don`t plead guilty... > -Ursprüngliche Nachricht- > Von: "Jan Engelhardt" <[EMAIL PROTECTED]> > Gesendet: 29.12.07 15:08:10 > An: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], Linux Kernel Mailing List > > Betreff: Re: kbuild: modules_install regression ? - depmod > > > On Dec 29 2007 14:30, [EMAIL PROTECTED] wrote: > >> On Dec 28 2007 16:08, [EMAIL PROTECTED] wrote: > >> > > >> >i have the same issue, but with 2.6.24-rc6 on a box with 512MB RAM > >> > > >> >System is openSUSE 10.3 > >> > >> If you enable CONFIG_DEBUG_INFO, don't be surprised. > > > >oh yes, that`s it! > > > >apparently CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_BUGVERBOSE and CONFIG_DEBUG_INFO > >defaults to "y" on my distro`s kernel, and i just copied config from > >/proc/config.gz and did a "make oldconfig". > > Erm... same system here - > > $ gzip -cd /proc/config.gz | grep DEBUG_INFO > # CONFIG_DEBUG_INFO is not set > > I think you managed to snafu something during building. > __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: modules_install regression ? - depmod
> [Adding jcm to Cc] > > On Dec 28 2007 16:08, [EMAIL PROTECTED] wrote: > > > >i have the same issue, but with 2.6.24-rc6 on a box with 512MB RAM > > > >System is openSUSE 10.3 > > > >on "make modules_install" , depmod reproduceably dies with out of memory > >error when it is ~800MB VSZ and ~350MB RSS > >this happens on different hardware. > > > >any clue what`s going wrong? > >how much memory should i expect being needed with "make modules_install" , > >e.g. with allmodconfig ? > > > If you enable CONFIG_DEBUG_INFO, don't be surprised. > oh yes, that`s it! apparently CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_BUGVERBOSE and CONFIG_DEBUG_INFO defaults to "y" on my distro`s kernel, and i just copied config from /proc/config.gz and did a "make oldconfig". after disabling those, all is fine now ! thanks for the hint! > Though I'd say depmod should ignore the debug sections. so depmod is acting sort of "stupid" here ? regards roland > > > > > > >Subject:kbuild: modules_install regression ? - depmod > >From: Jan-Simon =?utf-8?q?M=C3=B6ller?= > >Date: 2007-11-01 4:14:34 > >Message-ID: 200711010514.34469.dl9pf () gmx ! de > >[Download message RAW] > > > >Hi! > > > >I compiled kernel 2.6.24-rc1 (latest git as of today) on a Box with 256MB > >Ram. > >During "make modules_install" I got these errors: > > > > DEPMOD 2.6.24-rc1-default > >WARNING: Can't read > >module /lib/modules/2.6.24-rc1-default/kernel/net/bridge/bridge.ko: Cannot > >allocate memory > >WARNING: Can't read > >module > >/lib/modules/2.6.24-rc1-default/kernel/net/bridge/netfilter/ebt_redirect.ko: > >Cannot allocate memory > >[...] > >FATAL: Memory allocation failure depmod.c line 158: realloc(mod->deps, > >sizeof(mod->deps[0])*(mod->num_deps+1)). > >make: *** [_modinst_post] Fehler 1 > > > > > >Depmod used too much memory and exits. Tried a 2nd time and checked with top. > > > >IMHO this is a regression. > > > >best regards > >jan-simon > > > >__ > >Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! > > > >Mehr Infos unter http://produkte.web.de/club/?mc=021131 > > > >-- > >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > >the body of a message to [EMAIL PROTECTED] > >More majordomo info at http://vger.kernel.org/majordomo-info.html > >Please read the FAQ at http://www.tux.org/lkml/ > > > > __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: modules_install regression ? - depmod
[Adding jcm to Cc] On Dec 28 2007 16:08, [EMAIL PROTECTED] wrote: i have the same issue, but with 2.6.24-rc6 on a box with 512MB RAM System is openSUSE 10.3 on make modules_install , depmod reproduceably dies with out of memory error when it is ~800MB VSZ and ~350MB RSS this happens on different hardware. any clue what`s going wrong? how much memory should i expect being needed with make modules_install , e.g. with allmodconfig ? If you enable CONFIG_DEBUG_INFO, don't be surprised. oh yes, that`s it! apparently CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_BUGVERBOSE and CONFIG_DEBUG_INFO defaults to y on my distro`s kernel, and i just copied config from /proc/config.gz and did a make oldconfig. after disabling those, all is fine now ! thanks for the hint! Though I'd say depmod should ignore the debug sections. so depmod is acting sort of stupid here ? regards roland Subject:kbuild: modules_install regression ? - depmod From: Jan-Simon =?utf-8?q?M=C3=B6ller?= dl9pf () gmx ! de Date: 2007-11-01 4:14:34 Message-ID: 200711010514.34469.dl9pf () gmx ! de [Download message RAW] Hi! I compiled kernel 2.6.24-rc1 (latest git as of today) on a Box with 256MB Ram. During make modules_install I got these errors: DEPMOD 2.6.24-rc1-default WARNING: Can't read module /lib/modules/2.6.24-rc1-default/kernel/net/bridge/bridge.ko: Cannot allocate memory WARNING: Can't read module /lib/modules/2.6.24-rc1-default/kernel/net/bridge/netfilter/ebt_redirect.ko: Cannot allocate memory [...] FATAL: Memory allocation failure depmod.c line 158: realloc(mod-deps, sizeof(mod-deps[0])*(mod-num_deps+1)). make: *** [_modinst_post] Fehler 1 Depmod used too much memory and exits. Tried a 2nd time and checked with top. IMHO this is a regression. best regards jan-simon __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: modules_install regression ? - depmod
Erm... same system here - $ gzip -cd /proc/config.gz | grep DEBUG_INFO # CONFIG_DEBUG_INFO is not set I think you managed to snafu something during building. mhh - i have kernel-default-2.6.22.13-0.3 kernel (didn`t touch that since online update) and this has CONFIG_DEBUG_INFO=y wondering about that, i installed shipping kernel (kernel-default-2.6.22.5-31 from http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/i586/ ) but: opensuse103:~ # uname -a Linux opensuse103 2.6.22.5-31-default #1 SMP 2007/09/21 22:29:00 UTC i686 i686 i386 GNU/Linux opensuse103:~ # zcat /proc/config.gz |grep DEBUG_INFO CONFIG_DEBUG_INFO=y so i don`t plead guilty... -Ursprüngliche Nachricht- Von: Jan Engelhardt [EMAIL PROTECTED] Gesendet: 29.12.07 15:08:10 An: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], Linux Kernel Mailing List linux-kernel@vger.kernel.org Betreff: Re: kbuild: modules_install regression ? - depmod On Dec 29 2007 14:30, [EMAIL PROTECTED] wrote: On Dec 28 2007 16:08, [EMAIL PROTECTED] wrote: i have the same issue, but with 2.6.24-rc6 on a box with 512MB RAM System is openSUSE 10.3 If you enable CONFIG_DEBUG_INFO, don't be surprised. oh yes, that`s it! apparently CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_BUGVERBOSE and CONFIG_DEBUG_INFO defaults to y on my distro`s kernel, and i just copied config from /proc/config.gz and did a make oldconfig. Erm... same system here - $ gzip -cd /proc/config.gz | grep DEBUG_INFO # CONFIG_DEBUG_INFO is not set I think you managed to snafu something during building. __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: modules_install regression ? - depmod
i have the same issue, but with 2.6.24-rc6 on a box with 512MB RAM System is openSUSE 10.3 on "make modules_install" , depmod reproduceably dies with out of memory error when it is ~800MB VSZ and ~350MB RSS this happens on different hardware. any clue what`s going wrong? how much memory should i expect being needed with "make modules_install" , e.g. with allmodconfig ? Subject:kbuild: modules_install regression ? - depmod From: Jan-Simon =?utf-8?q?M=C3=B6ller?= Date: 2007-11-01 4:14:34 Message-ID: 200711010514.34469.dl9pf () gmx ! de [Download message RAW] Hi! I compiled kernel 2.6.24-rc1 (latest git as of today) on a Box with 256MB Ram. During "make modules_install" I got these errors: DEPMOD 2.6.24-rc1-default WARNING: Can't read module /lib/modules/2.6.24-rc1-default/kernel/net/bridge/bridge.ko: Cannot allocate memory WARNING: Can't read module /lib/modules/2.6.24-rc1-default/kernel/net/bridge/netfilter/ebt_redirect.ko: Cannot allocate memory [...] FATAL: Memory allocation failure depmod.c line 158: realloc(mod->deps, sizeof(mod->deps[0])*(mod->num_deps+1)). make: *** [_modinst_post] Fehler 1 Depmod used too much memory and exits. Tried a 2nd time and checked with top. IMHO this is a regression. best regards jan-simon __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild: modules_install regression ? - depmod
i have the same issue, but with 2.6.24-rc6 on a box with 512MB RAM System is openSUSE 10.3 on make modules_install , depmod reproduceably dies with out of memory error when it is ~800MB VSZ and ~350MB RSS this happens on different hardware. any clue what`s going wrong? how much memory should i expect being needed with make modules_install , e.g. with allmodconfig ? Subject:kbuild: modules_install regression ? - depmod From: Jan-Simon =?utf-8?q?M=C3=B6ller?= dl9pf () gmx ! de Date: 2007-11-01 4:14:34 Message-ID: 200711010514.34469.dl9pf () gmx ! de [Download message RAW] Hi! I compiled kernel 2.6.24-rc1 (latest git as of today) on a Box with 256MB Ram. During make modules_install I got these errors: DEPMOD 2.6.24-rc1-default WARNING: Can't read module /lib/modules/2.6.24-rc1-default/kernel/net/bridge/bridge.ko: Cannot allocate memory WARNING: Can't read module /lib/modules/2.6.24-rc1-default/kernel/net/bridge/netfilter/ebt_redirect.ko: Cannot allocate memory [...] FATAL: Memory allocation failure depmod.c line 158: realloc(mod-deps, sizeof(mod-deps[0])*(mod-num_deps+1)). make: *** [_modinst_post] Fehler 1 Depmod used too much memory and exits. Tried a 2nd time and checked with top. IMHO this is a regression. best regards jan-simon __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
broken modules - hgafb and physmap !?
i did some module tests with 2.6.24-rc kernel (suse) and think i found some issues with modules. for some of those i found i`m not yet sure if they are mainline issues, but the following should exist in mainline too (see below) i searched this list and also bugzilla and found no reference there, so maybe it`s worth posting it here. anyway, these are probably minor/cosmetic. modprobe hgafb; rmmod hgafb modprobe physmap;rmmod physmap hgafb: HGA card not detected. hgafb: probe of hgafb.0 failed with error -22 Device 'hgafb.0' does not have a release() function, it is broken and must be fixed. WARNING: at drivers/base/core.c:107 device_release() [] kobject_cleanup+0x3d/0x54 [] kobject_release+0x0/0x8 [] kref_put+0x60/0x6d [] platform_device_del+0x12/0x37 [] hgafb_exit+0xa/0x14 [hgafb] [] sys_delete_module+0x190/0x1c0 [] remove_vma+0x36/0x3b [] sysenter_past_esp+0x6b/0xa9 === physmap platform flash device: 0400 at 0800 physmap-flash physmap-flash.0: Could not reserve memory region physmap-flash: probe of physmap-flash.0 failed with error -12 Device 'physmap-flash.0' does not have a release() function, it is broken and must be fixed. WARNING: at drivers/base/core.c:107 device_release() [] kobject_cleanup+0x3d/0x54 [] kobject_release+0x0/0x8 [] kref_put+0x60/0x6d [] platform_device_del+0x2b/0x37 [] physmap_exit+0xa/0x14 [physmap] [] sys_delete_module+0x190/0x1c0 [] remove_vma+0x36/0x3b [] sysenter_past_esp+0x6b/0xa9 === _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
broken modules - hgafb and physmap !?
i did some module tests with 2.6.24-rc kernel (suse) and think i found some issues with modules. for some of those i found i`m not yet sure if they are mainline issues, but the following should exist in mainline too (see below) i searched this list and also bugzilla and found no reference there, so maybe it`s worth posting it here. anyway, these are probably minor/cosmetic. modprobe hgafb; rmmod hgafb modprobe physmap;rmmod physmap hgafb: HGA card not detected. hgafb: probe of hgafb.0 failed with error -22 Device 'hgafb.0' does not have a release() function, it is broken and must be fixed. WARNING: at drivers/base/core.c:107 device_release() [c01ccd15] kobject_cleanup+0x3d/0x54 [c01ccd2c] kobject_release+0x0/0x8 [c01cd8d4] kref_put+0x60/0x6d [c023fb77] platform_device_del+0x12/0x37 [e0a7c4f2] hgafb_exit+0xa/0x14 [hgafb] [c014170c] sys_delete_module+0x190/0x1c0 [c0161176] remove_vma+0x36/0x3b [c0104e22] sysenter_past_esp+0x6b/0xa9 === physmap platform flash device: 0400 at 0800 physmap-flash physmap-flash.0: Could not reserve memory region physmap-flash: probe of physmap-flash.0 failed with error -12 Device 'physmap-flash.0' does not have a release() function, it is broken and must be fixed. WARNING: at drivers/base/core.c:107 device_release() [c01ccd15] kobject_cleanup+0x3d/0x54 [c01ccd2c] kobject_release+0x0/0x8 [c01cd8d4] kref_put+0x60/0x6d [c023fb90] platform_device_del+0x2b/0x37 [e0aa42ca] physmap_exit+0xa/0x14 [physmap] [c014170c] sys_delete_module+0x190/0x1c0 [c0161176] remove_vma+0x36/0x3b [c0104e22] sysenter_past_esp+0x6b/0xa9 === _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
> > not sure if really all of them are the edd problem i have, but i`m quite > > sure for some of those. > > can provide more links if somebody likes. > > None of them seemed like they were determined as EDD problems - so - see how difficult it is to determine, what`s the problem is ? ;) >some even did not work with edd=skipmbr. on my 2 problematic systems, edd=skipmbr doesn`t help. only edd=off helps. > But that is not the point. Problem is not widely known, likely happens > with very old BIOSes and people who use those systems should be > knowing more than simply booting back to Win98. i don`t see any relation to what a user knows and what kind of system of what age he is using. > And if those people are smart enough to figure out the right place to > ask - they will likely get suggestions to do edd=off like some of the > above links that you posted prove - without the message. see - and THATS where our opinion probably differs very much from mine. i think, user`s don`t want an operating system at all. they want that their computer just works and that they can use their apps. us linux fans have fun with debugging things and make them work,helping others and that stuff - but others just don`t want to search for the magic token to make their computer boot. if windows just boots on that system, so should linux. if it doesn`t, they should be able to fix this without being an expert. > Why tax other people with a warning/hang etc. in printk when the > problem is very unlikely on their systems? i don`t have a clue how likely or unlikely the problem is. i have seen that problem more than once and i know people who also can tell you about. > So you think those people with such low tech knowledge will figure out > the right mailing list, make sense of the output of EDD message and > then post the question? Or that they will figure out how to specify > the edd=off to kernel command line? In that use case - not doing EDD > on their boxes like I said would be the most useful thing to do. A > message or 3 is useless in this case. at least they could get help by any other linux user with average experience. but a blinking cursor in the upper left is nothing an average linux user is being able to implicate with EDD. > But yeah whatever - if you cut it down to one printk line and remove > the hang word that would at least be bearable :) ok. i think i`m making to much noise for too few lines of code, so let`s stop discussing. but let`s wait for some more comments. maybe some simple "probing edd" is a diplomatic solution and at least better than nothing. regards roland _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
> This is awfully verbose.
yes, this was meant as an example
also mind, that the last printf with "\rOK" is meant to overwrite the hint
message, so nobody should ever notice that message. i`m just unsure if this is
a good approach. i have found two occurences in linux kernel, where drivers do
something similar.
> [or even "failed"...]
yes, but how to detect if we got stuck forever inside that bios probe ?
i assume that`s hard to do, so that`s why i`m printing that hint "into the
future", to be overwritten on successful return.
> Also, you really should look for the "quiet" command-line option and
> squelch the message.
sure! will add that if there is some positive feedback and someone finds this
patch useful.
regards
roland
> -Ursprüngliche Nachricht-
> Von: "H. Peter Anvin" <[EMAIL PROTECTED]>
> Gesendet: 16.12.07 19:17:40
> An: [EMAIL PROTECTED]
> CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED]
> Betreff: Re: [PATCH] [RFC] be more verbose when probing EDD
>
> [EMAIL PROTECTED] wrote:
> > /* Query EDD information */
> > #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
> > - query_edd();
> > +printf("Probing EDD (query Bios for boot-device information)\n");
> > +printf("If boot hangs here, you may have a buggy Bios. Try
> > edd=skipmbr or edd=off");
> > +query_edd();
> > +printf("\rOK
> > \n");
> > #endif
>
> This is awfully verbose.
>
> I'd prefer something like:
>
> printf("Probing EDD BIOS... ");
> query_edd();
> printf("ok\n");
>
> [or even "failed"...]
>
> Also, you really should look for the "quiet" command-line option and
> squelch the message.
>
> -hpa
>
___
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
> It does not look like this issue is common - googling for "Linux EDD Boot > hang" does not bring up relevant and recent results - in fact this post of > yours comes on top. i don`t wonder here - how should one know that it`s an edd problem if all he sees is a blank screen with a blinking cursor in the upper left ? so i assume, "Linux EDD Boot hang" isn`t the best term for searching here. i think, there is no universal search phrase - i found some references with different words (linux install, blank screen, blinking cursor) some of them http://forums.suselinuxsupport.de/lofiversion/index.php/t61581.html http://suseforums.net/index.php?showtopic=1302 http://forums.suselinuxsupport.de/lofiversion/index.php/t3157.html http://www.linuxforums.org/forum/installation/73984-cant-boot-past-loading-kernel-fedora-4-a.html http://ubuntuforums.org/archive/index.php/t-146180.html http://ubuntuforums.org/showthread.php?t=450630 http://www.linuxquestions.org/questions/linux-software-2/grub-freezes-before-uncompressing-kernel-464619/ not sure if really all of them are the edd problem i have, but i`m quite sure for some of those. can provide more links if somebody likes. > Adding 3 printks for each such obscure problem would make it even more i wouldn`t call that problem obscure. i have seen this problem more than 5 times since that code is in linux. so it`s at least enough to discuss about even if no other person thinks it`s necessary :) just the fact that it`s not been discussed often (here or elsewhere) doesn`t mean, that it exist or that users come across that. it`s more that type of "mhh, let`s try linux instead of windows. oh, doesn`t boot. ok, let`s stay with windows then...". you don`t expect people like those posting the right question to the right forum, do you? > If there are known chipsets / BIOSes that have this problem - applying > quirks - something like this quirk for pmtmr [1]- (if they work this > early) or even special casing them with forced edd=off may be the right and > more useful thing to do. mhh. i`m unsure. ok, i`m no kernel-hacker but there are so many variants of bios/hardware out there so blacklisting certain bios versions may be never more than half of a solution. roland > -Ursprüngliche Nachricht- > Von: "Parag Warudkar" <[EMAIL PROTECTED]> > Gesendet: 16.12.07 18:34:48 > An: [EMAIL PROTECTED] > CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED] > Betreff: Re: [PATCH] [RFC] be more verbose when probing EDD > > On Sun, 16 Dec 2007, [EMAIL PROTECTED] wrote: > > > > > - it seems there are buggy Bios implementations out there which have > > problems with EDD > > - your favourite distro may have set CONFIG_EDD=y|m , so EDD probe is on by > > default quite often nowadays. > > - setting "edd=off" when you get that hang on boot is _not_ obvious. > > It does not look like this issue is common - googling for "Linux EDD Boot > hang" does not bring up relevant and recent results - in fact this post of > yours comes on top. Further more there does not seem to be problems with > newer BIOSes so we would be irritating lot many users needlessly. > > Adding 3 printks for each such obscure problem would make it even more > complex to parse and make sense of the boot log - I, for example, already > dislike the mostly-useless-to-end-user stuff it spews on a normal boot. > > If there are known chipsets / BIOSes that have this problem - applying > quirks - something like this quirk for pmtmr [1]- (if they work this > early) or even special casing them with forced edd=off may be the right and > more useful thing to do. > > [1] http://www.webservertalk.com/archive242-2006-3-1447442.html > > Parag > ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RFC] be more verbose when probing EDD
Hello!
i`m sysadmin for quite some time and while being that, i have come across the
one or another system, which refused to boot a linux kernel. typical symptom i
have seen is a blinking cursor in the upper left just after kernel/initrd were
loaded.
i never spent much time on that and either choose another system for linux or
choose "failsafe" option, if the installer of my favourite distro gave that
option.
since a colleague of mine was hit by that problem some weeks ago and i also
came across that again recently, i started to investigate deeper and found,
that EDD Bios probe is the problem here.
i found more than a handful of references on the net where people report
similar problems. many discussion threads contained that typical smattering
babble and seldom somebody gave that essential hint "try edd=off" for which i`m
sure it would have helped many times.
that`s why i started to spend some thoughts on this how to make this
easier/better for the user.
so
- it seems there are buggy Bios implementations out there which have problems
with EDD
- your favourite distro may have set CONFIG_EDD=y|m , so EDD probe is on by
default quite often nowadays.
- setting "edd=off" when you get that hang on boot is _not_ obvious.
- adressing this issue may be a little bit late, since i have mostly seen that
problem on older machines, but not on recently bought
- i have at least two different systems with different types of chipsets to
demonstrate this
on one of those, i added some printf`s to edd.c and this routine seems to be
problematic and never returns
/* Extended Get Device Parameters */
ei->params.length = sizeof(ei->params);
ax = 0x4800;
dx = devno;
asm("pushfl; int $0x13; popfl"
: "+a" (ax), "+d" (dx), "=m" (ei->params)
: "S" (>params)
: "ebx", "ecx", "edi");
i had a short conversation with matt domsch and hpa, who both think that
additional printf`s would be an easy solution and not too bad to be added.
here is a quick and dirty initial patch from me:
--- linux-2.6.23/arch/x86/boot/main.c.orig 2007-12-09 11:40:24.315346712
+0100
+++ linux-2.6.23/arch/x86/boot/main.c 2007-12-09 16:11:43.644512504 +0100
@@ -152,7 +152,10 @@
/* Query EDD information */
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
- query_edd();
+printf("Probing EDD (query Bios for boot-device information)\n");
+printf("If boot hangs here, you may have a buggy Bios. Try edd=skipmbr
or edd=off");
+query_edd();
+printf("\rOK
\n");
#endif
/* Do the last things and invoke protected mode */
go_to_protected_mode();
ok, fore sure it`s better to do that stuff in query_edd() itself, but before
making a better version, i`d like to discuss if such patch would get accepted
at all and if it`s a valid approach to let the kernel print some line which
get`s overwritten ("\rOK + lot`s of whitespaces") milliseconds later on
successful function return.
regards
roland
__
Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit
Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RFC] be more verbose when probing EDD
Hello! i`m sysadmin for quite some time and while being that, i have come across the one or another system, which refused to boot a linux kernel. typical symptom i have seen is a blinking cursor in the upper left just after kernel/initrd were loaded. i never spent much time on that and either choose another system for linux or choose failsafe option, if the installer of my favourite distro gave that option. since a colleague of mine was hit by that problem some weeks ago and i also came across that again recently, i started to investigate deeper and found, that EDD Bios probe is the problem here. i found more than a handful of references on the net where people report similar problems. many discussion threads contained that typical smattering babble and seldom somebody gave that essential hint try edd=off for which i`m sure it would have helped many times. that`s why i started to spend some thoughts on this how to make this easier/better for the user. so - it seems there are buggy Bios implementations out there which have problems with EDD - your favourite distro may have set CONFIG_EDD=y|m , so EDD probe is on by default quite often nowadays. - setting edd=off when you get that hang on boot is _not_ obvious. - adressing this issue may be a little bit late, since i have mostly seen that problem on older machines, but not on recently bought - i have at least two different systems with different types of chipsets to demonstrate this on one of those, i added some printf`s to edd.c and this routine seems to be problematic and never returns /* Extended Get Device Parameters */ ei-params.length = sizeof(ei-params); ax = 0x4800; dx = devno; asm(pushfl; int $0x13; popfl : +a (ax), +d (dx), =m (ei-params) : S (ei-params) : ebx, ecx, edi); i had a short conversation with matt domsch and hpa, who both think that additional printf`s would be an easy solution and not too bad to be added. here is a quick and dirty initial patch from me: --- linux-2.6.23/arch/x86/boot/main.c.orig 2007-12-09 11:40:24.315346712 +0100 +++ linux-2.6.23/arch/x86/boot/main.c 2007-12-09 16:11:43.644512504 +0100 @@ -152,7 +152,10 @@ /* Query EDD information */ #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE) - query_edd(); +printf(Probing EDD (query Bios for boot-device information)\n); +printf(If boot hangs here, you may have a buggy Bios. Try edd=skipmbr or edd=off); +query_edd(); +printf(\rOK \n); #endif /* Do the last things and invoke protected mode */ go_to_protected_mode(); ok, fore sure it`s better to do that stuff in query_edd() itself, but before making a better version, i`d like to discuss if such patch would get accepted at all and if it`s a valid approach to let the kernel print some line which get`s overwritten (\rOK + lot`s of whitespaces) milliseconds later on successful function return. regards roland __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
It does not look like this issue is common - googling for Linux EDD Boot hang does not bring up relevant and recent results - in fact this post of yours comes on top. i don`t wonder here - how should one know that it`s an edd problem if all he sees is a blank screen with a blinking cursor in the upper left ? so i assume, Linux EDD Boot hang isn`t the best term for searching here. i think, there is no universal search phrase - i found some references with different words (linux install, blank screen, blinking cursor) some of them http://forums.suselinuxsupport.de/lofiversion/index.php/t61581.html http://suseforums.net/index.php?showtopic=1302 http://forums.suselinuxsupport.de/lofiversion/index.php/t3157.html http://www.linuxforums.org/forum/installation/73984-cant-boot-past-loading-kernel-fedora-4-a.html http://ubuntuforums.org/archive/index.php/t-146180.html http://ubuntuforums.org/showthread.php?t=450630 http://www.linuxquestions.org/questions/linux-software-2/grub-freezes-before-uncompressing-kernel-464619/ not sure if really all of them are the edd problem i have, but i`m quite sure for some of those. can provide more links if somebody likes. Adding 3 printks for each such obscure problem would make it even more i wouldn`t call that problem obscure. i have seen this problem more than 5 times since that code is in linux. so it`s at least enough to discuss about even if no other person thinks it`s necessary :) just the fact that it`s not been discussed often (here or elsewhere) doesn`t mean, that it exist or that users come across that. it`s more that type of mhh, let`s try linux instead of windows. oh, doesn`t boot. ok, let`s stay with windows then you don`t expect people like those posting the right question to the right forum, do you? If there are known chipsets / BIOSes that have this problem - applying quirks - something like this quirk for pmtmr [1]- (if they work this early) or even special casing them with forced edd=off may be the right and more useful thing to do. mhh. i`m unsure. ok, i`m no kernel-hacker but there are so many variants of bios/hardware out there so blacklisting certain bios versions may be never more than half of a solution. roland -Ursprüngliche Nachricht- Von: Parag Warudkar [EMAIL PROTECTED] Gesendet: 16.12.07 18:34:48 An: [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [PATCH] [RFC] be more verbose when probing EDD On Sun, 16 Dec 2007, [EMAIL PROTECTED] wrote: - it seems there are buggy Bios implementations out there which have problems with EDD - your favourite distro may have set CONFIG_EDD=y|m , so EDD probe is on by default quite often nowadays. - setting edd=off when you get that hang on boot is _not_ obvious. It does not look like this issue is common - googling for Linux EDD Boot hang does not bring up relevant and recent results - in fact this post of yours comes on top. Further more there does not seem to be problems with newer BIOSes so we would be irritating lot many users needlessly. Adding 3 printks for each such obscure problem would make it even more complex to parse and make sense of the boot log - I, for example, already dislike the mostly-useless-to-end-user stuff it spews on a normal boot. If there are known chipsets / BIOSes that have this problem - applying quirks - something like this quirk for pmtmr [1]- (if they work this early) or even special casing them with forced edd=off may be the right and more useful thing to do. [1] http://www.webservertalk.com/archive242-2006-3-1447442.html Parag ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
This is awfully verbose. yes, this was meant as an example also mind, that the last printf with \rOK is meant to overwrite the hint message, so nobody should ever notice that message. i`m just unsure if this is a good approach. i have found two occurences in linux kernel, where drivers do something similar. [or even failed...] yes, but how to detect if we got stuck forever inside that bios probe ? i assume that`s hard to do, so that`s why i`m printing that hint into the future, to be overwritten on successful return. Also, you really should look for the quiet command-line option and squelch the message. sure! will add that if there is some positive feedback and someone finds this patch useful. regards roland -Ursprüngliche Nachricht- Von: H. Peter Anvin [EMAIL PROTECTED] Gesendet: 16.12.07 19:17:40 An: [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED] Betreff: Re: [PATCH] [RFC] be more verbose when probing EDD [EMAIL PROTECTED] wrote: /* Query EDD information */ #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE) - query_edd(); +printf(Probing EDD (query Bios for boot-device information)\n); +printf(If boot hangs here, you may have a buggy Bios. Try edd=skipmbr or edd=off); +query_edd(); +printf(\rOK \n); #endif This is awfully verbose. I'd prefer something like: printf(Probing EDD BIOS... ); query_edd(); printf(ok\n); [or even failed...] Also, you really should look for the quiet command-line option and squelch the message. -hpa ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
not sure if really all of them are the edd problem i have, but i`m quite sure for some of those. can provide more links if somebody likes. None of them seemed like they were determined as EDD problems - so - see how difficult it is to determine, what`s the problem is ? ;) some even did not work with edd=skipmbr. on my 2 problematic systems, edd=skipmbr doesn`t help. only edd=off helps. But that is not the point. Problem is not widely known, likely happens with very old BIOSes and people who use those systems should be knowing more than simply booting back to Win98. i don`t see any relation to what a user knows and what kind of system of what age he is using. And if those people are smart enough to figure out the right place to ask - they will likely get suggestions to do edd=off like some of the above links that you posted prove - without the message. see - and THATS where our opinion probably differs very much from mine. i think, user`s don`t want an operating system at all. they want that their computer just works and that they can use their apps. us linux fans have fun with debugging things and make them work,helping others and that stuff - but others just don`t want to search for the magic token to make their computer boot. if windows just boots on that system, so should linux. if it doesn`t, they should be able to fix this without being an expert. Why tax other people with a warning/hang etc. in printk when the problem is very unlikely on their systems? i don`t have a clue how likely or unlikely the problem is. i have seen that problem more than once and i know people who also can tell you about. So you think those people with such low tech knowledge will figure out the right mailing list, make sense of the output of EDD message and then post the question? Or that they will figure out how to specify the edd=off to kernel command line? In that use case - not doing EDD on their boxes like I said would be the most useful thing to do. A message or 3 is useless in this case. at least they could get help by any other linux user with average experience. but a blinking cursor in the upper left is nothing an average linux user is being able to implicate with EDD. But yeah whatever - if you cut it down to one printk line and remove the hang word that would at least be bearable :) ok. i think i`m making to much noise for too few lines of code, so let`s stop discussing. but let`s wait for some more comments. maybe some simple probing edd is a diplomatic solution and at least better than nothing. regards roland _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ata_piix init/performance regression ?
Hello ! on my old fujitsu-siemens lifebook, booting is at least 20 seconds slower as before. on ata_piix init i can see 2 longer delays of ~10 seconds each, which didn`t happen before. i`m using SuSE kernel of the day from http://ftp.suse.com/pub/projects/kernel/kotd/ problem exists with these kernels: kernel-vanilla-2.6.24_rc3_git3-20071201095839 kernel-default-2.6.24_rc3_git3-20071201095839 kernel-default-2.6.24_rc4_git3-20071206172629 kernel-vanilla-2.6.24_rc4_git3-20071206172629 problem didn`t exist with this one: kernel-default-2.6.22.12-0.1 (opensuse 10.3 default) please see https://bugzilla.novell.com/show_bug.cgi?id=345442 for more details. regards roland _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ata_piix init/performance regression ?
Hello ! on my old fujitsu-siemens lifebook, booting is at least 20 seconds slower as before. on ata_piix init i can see 2 longer delays of ~10 seconds each, which didn`t happen before. i`m using SuSE kernel of the day from http://ftp.suse.com/pub/projects/kernel/kotd/ problem exists with these kernels: kernel-vanilla-2.6.24_rc3_git3-20071201095839 kernel-default-2.6.24_rc3_git3-20071201095839 kernel-default-2.6.24_rc4_git3-20071206172629 kernel-vanilla-2.6.24_rc4_git3-20071206172629 problem didn`t exist with this one: kernel-default-2.6.22.12-0.1 (opensuse 10.3 default) please see https://bugzilla.novell.com/show_bug.cgi?id=345442 for more details. regards roland _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Re: System reboot triggered by just reading a device file....!?
Hi Clemens, > > Hi, Roland! > > Please don't top-post. sorry! > > > [was: it would be easy to disable the kernel watchdog] > > thanks, but i know i could do this. > > Good. I was also curious and just checked again. The watchdog subsystem > is by default _disabled_ in the kernel configuration. If you use some > distro's kernel, where they turned it on, complain to them! > If you turned it on yourself, you are really on your own... > the Kconfig help there is IMO sufficient and very clear and, > "If unsure, say N". Hmm... sorry?! whoops - sorry for that. i should have checked that, but i think i just didn`t expect some distro vendor to change that default. sure i will complain to suse now. stopping getting on your nerves here, now. > > this thread is not meant to protect myself from this curiousity but it is > meant > > to protect others. it`s a trap. > > I guess I understand your position. But I don't see no way to improve > the kernel in that point. > Complain to the guys who enabled the watchdog / setup this trap for > any reason. sure. you`re completely right. > > i stepped into that. > > now i know that trap, so i can easily sidestep. > > it maybe very seldom that someone steps into this. > > but it may happen and then someone will have trouble and spend time on > this. > > i think every admin can tell you about weird random reboots of his systems > > which he cannot explain what was the reason for it. > > That's one possible way of "learning by doing suicide (tm);" :) > > this maybe some of those reasons and this one could be avoided. > > i`m thinking of something simple like echo "now you`re armed" > > /dev/watchdog > > Read some details about watchdogs to get more background and why the > watchdog is triggered so easily and why it's good this way. > i.e: http://www.ganssle.com/watchdogs.pdf thanks for your help and for that very useful link. that`s the very best stuff i every read about watchdogs! regards Roland __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Re: System reboot triggered by just reading a device file....!?
Hi Clemens, Hi, Roland! Please don't top-post. sorry! [was: it would be easy to disable the kernel watchdog] thanks, but i know i could do this. Good. I was also curious and just checked again. The watchdog subsystem is by default _disabled_ in the kernel configuration. If you use some distro's kernel, where they turned it on, complain to them! If you turned it on yourself, you are really on your own... the Kconfig help there is IMO sufficient and very clear and, If unsure, say N. Hmm... sorry?! whoops - sorry for that. i should have checked that, but i think i just didn`t expect some distro vendor to change that default. sure i will complain to suse now. stopping getting on your nerves here, now. this thread is not meant to protect myself from this curiousity but it is meant to protect others. it`s a trap. I guess I understand your position. But I don't see no way to improve the kernel in that point. Complain to the guys who enabled the watchdog / setup this trap for any reason. sure. you`re completely right. i stepped into that. now i know that trap, so i can easily sidestep. it maybe very seldom that someone steps into this. but it may happen and then someone will have trouble and spend time on this. i think every admin can tell you about weird random reboots of his systems which he cannot explain what was the reason for it. That's one possible way of learning by doing suicide (tm); :) this maybe some of those reasons and this one could be avoided. i`m thinking of something simple like echo now you`re armed /dev/watchdog Read some details about watchdogs to get more background and why the watchdog is triggered so easily and why it's good this way. i.e: http://www.ganssle.com/watchdogs.pdf thanks for your help and for that very useful link. that`s the very best stuff i every read about watchdogs! regards Roland __ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System reboot triggered by just reading a device file....!?
Hi Clemens, thanks, but i know i could do this. this thread is not meant to protect myself from this curiousity but it is meant to protect others. it`s a trap. i stepped into that. now i know that trap, so i can easily sidestep. but most people using linux don`t know about the watchdog, so i don`t think they will know about this trap. you can`t make that become common knowledge. and we can`t expect that they will find out _what`s_ the trap at all, if they step into. having this behaviour documented is like putting a sign "don`t step into this" at the back of the trap so why shouldn`t we help them avoiding it ? it maybe very seldom that someone steps into this. but it may happen and then someone will have trouble and spend time on this. i think every admin can tell you about weird random reboots of his systems which he cannot explain what was the reason for it. this maybe some of those reasons and this one could be avoided. i`m thinking of something simple like echo "now you`re armed" > /dev/watchdog regards roland > -Ursprüngliche Nachricht- > Von: "Clemens Koller" <[EMAIL PROTECTED]> > Gesendet: 22.11.07 21:43:15 > An: [EMAIL PROTECTED] > CC: Simon Arlott <[EMAIL PROTECTED]>, Robert Hancock <[EMAIL PROTECTED]>, > linux-kernel@vger.kernel.org > Betreff: Re: System reboot triggered by just reading a device file!? > > [EMAIL PROTECTED] schrieb: > > > [was: reading /dev/watchdog triggers reboot as intended] > > need to change my own philosophy now, because i learned that reading isn`t > harmless. ;) > > If you want to protect you from your curiosity (or from reading anything), > you could just disable the watchdog in the kernel. > See: Device Drivers -> Character devices -> Watchdog Timer Support -> ... > > Regards, > -- > Clemens Koller > __ > R Imaging Devices > Anagramm GmbH > Rupert-Mayer-Straße 45/1 > Linhof Werksgelände > D-81379 München > Tel.089-741518-50 > Fax 089-741518-19 > http://www.anagramm-technology.com > __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System reboot triggered by just reading a device file....!?
since i have gotten more or less similar answers from here, i have talked to some more people privately. the result is interesting: if the person i talked to was some sysadmin or related to that (i.e. some person running servers), his opinion was very similar to mine. if the person was a developer, he didn`t really understand why i have a problem with that. "be careful if you are root" was what i got. one of the admins gave a good statement, which i liked very much and want to share: "even if you are root: it`s unix philosophy, that reading is harmless!" i never thought about that, but i think that`s exactly the point and that`s why i`m feeling uncomfortable with that. anyway - it cost me some time to find a bug which was none and the only mistake i did was using a tool for which i was sure did nothing more than reading. so why should i care that i was root ? need to change my own philosophy now, because i learned that reading isn`t harmless. ;) regards roland > -Ursprüngliche Nachricht- > Von: "Simon Arlott" <[EMAIL PROTECTED]> > Gesendet: 21.11.07 13:30:05 > An: [EMAIL PROTECTED] > CC: "Robert Hancock" <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org > Betreff: Re: System reboot triggered by just reading a device file!? > > On Wed, November 21, 2007 00:01, [EMAIL PROTECTED] wrote: > >>There is.. it's called "root privileges". > > yes, true. > > > > but - regardless of being a windows app or not - what if you want to take a > > look on your system as a whole, > > especially when using some tool which graphically shows how and where your > > diskspace is being used? if i > > let this run from ordinary useraccount it would get lot`s of "permission > > denied" and then it`s only telling > > half of the truth. > > Such a tool shouldn't need to open any files, whether they're device files or > not. Do you expect it to open > /dev/zero etc. too and read from an infinitely sized "file"? > > >> > i`d wish there would be some fence around this or iTCO_wdt /dev/watchdog > >> > not being active after a > >> default desktop installation. > > Delete it? > > -- > Simon Arlott > __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System reboot triggered by just reading a device file....!?
since i have gotten more or less similar answers from here, i have talked to some more people privately. the result is interesting: if the person i talked to was some sysadmin or related to that (i.e. some person running servers), his opinion was very similar to mine. if the person was a developer, he didn`t really understand why i have a problem with that. be careful if you are root was what i got. one of the admins gave a good statement, which i liked very much and want to share: even if you are root: it`s unix philosophy, that reading is harmless! i never thought about that, but i think that`s exactly the point and that`s why i`m feeling uncomfortable with that. anyway - it cost me some time to find a bug which was none and the only mistake i did was using a tool for which i was sure did nothing more than reading. so why should i care that i was root ? need to change my own philosophy now, because i learned that reading isn`t harmless. ;) regards roland -Ursprüngliche Nachricht- Von: Simon Arlott [EMAIL PROTECTED] Gesendet: 21.11.07 13:30:05 An: [EMAIL PROTECTED] CC: Robert Hancock [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: System reboot triggered by just reading a device file!? On Wed, November 21, 2007 00:01, [EMAIL PROTECTED] wrote: There is.. it's called root privileges. yes, true. but - regardless of being a windows app or not - what if you want to take a look on your system as a whole, especially when using some tool which graphically shows how and where your diskspace is being used? if i let this run from ordinary useraccount it would get lot`s of permission denied and then it`s only telling half of the truth. Such a tool shouldn't need to open any files, whether they're device files or not. Do you expect it to open /dev/zero etc. too and read from an infinitely sized file? i`d wish there would be some fence around this or iTCO_wdt /dev/watchdog not being active after a default desktop installation. Delete it? -- Simon Arlott __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System reboot triggered by just reading a device file....!?
Hi Clemens, thanks, but i know i could do this. this thread is not meant to protect myself from this curiousity but it is meant to protect others. it`s a trap. i stepped into that. now i know that trap, so i can easily sidestep. but most people using linux don`t know about the watchdog, so i don`t think they will know about this trap. you can`t make that become common knowledge. and we can`t expect that they will find out _what`s_ the trap at all, if they step into. having this behaviour documented is like putting a sign don`t step into this at the back of the trap so why shouldn`t we help them avoiding it ? it maybe very seldom that someone steps into this. but it may happen and then someone will have trouble and spend time on this. i think every admin can tell you about weird random reboots of his systems which he cannot explain what was the reason for it. this maybe some of those reasons and this one could be avoided. i`m thinking of something simple like echo now you`re armed /dev/watchdog regards roland -Ursprüngliche Nachricht- Von: Clemens Koller [EMAIL PROTECTED] Gesendet: 22.11.07 21:43:15 An: [EMAIL PROTECTED] CC: Simon Arlott [EMAIL PROTECTED], Robert Hancock [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: System reboot triggered by just reading a device file!? [EMAIL PROTECTED] schrieb: [was: reading /dev/watchdog triggers reboot as intended] need to change my own philosophy now, because i learned that reading isn`t harmless. ;) If you want to protect you from your curiosity (or from reading anything), you could just disable the watchdog in the kernel. See: Device Drivers - Character devices - Watchdog Timer Support - ... Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com __ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System reboot triggered by just reading a device file....!?
>There is.. it's called "root privileges".
yes, true.
but - regardless of being a windows app or not - what if you want to take a
look on your system as a whole, especially when using some tool which
graphically shows how and where your diskspace is being used? if i let this
run from ordinary useraccount it would get lot`s of "permission denied" and
then it`s only telling half of the truth.
>I'd say running pretty much anything through Wine as root is
> not a good idea, a Windows app could hose the system without even
> meaning to through exactly such things.
yes, true indeed. but maybe wine has an option to sandbox the windows app to do
only r/o access. if that feature doesn`t exist, (set r/o flag to dosdevices)
maybe it would be an useful addon.
but that`s OT here
> -Ursprüngliche Nachricht-
> Von: "Robert Hancock" <[EMAIL PROTECTED]>
> Gesendet: 21.11.07 00:35:23
> An: [EMAIL PROTECTED]
> CC: linux-kernel@vger.kernel.org
> Betreff: Re: System reboot triggered by just reading a device file!?
>
> [EMAIL PROTECTED] wrote:
> > good evening,
> >
> > i stumbled over some funny issue when trying windirstat (like KDirStat)
> > with wine.
> >
> > after running that tool for a while my system rebooted. i could reproduce
> > this with every run.
> >
> > after some deep investigation (i thought i had stability issues with my
> > system and spent more than an hour on this) i found out, that the reboot is
> > being triggered by iTCO_wdt ( /dev/watchdog )
> >
> > this is how to reproduce:
> >
> > - be root
> > - cat /dev/watchdog or dd if=/dev/watchdog of=/dev/zero bs=1 count=1 or
> > .
> > - wait one minute
> >
> > *reboot*!
> >
> > i have heard 2 opinions for now (contacted the author and also discussed on
> > wine-devel ) that this should be expected behaviour.
>
> Yes, it is. It's a watchdog device, it's meant to reboot the machine if
> whatever task is poking the watchdog dies.
>
> > being sysadmin quite a while, i cannot believe that (accidentally) reading
> > a device file (being root or not - what does that matter) triggers a system
> > reboot.
> >
> > ok - when i`m root , i shouldn`t do stupid things and be careful, but i
> > thought reading/crawling trough a filesystem (r/o, btw.) with some tool
> > which is built to do exactly this wasn`t so stupid - even from within wine.
>
> I would say that running a Windows tool that opens up and reads random
> files, on the /dev directory tree, as root, probably does qualify as
> "stupid". I'd say running pretty much anything through Wine as root is
> not a good idea, a Windows app could hose the system without even
> meaning to through exactly such things.
>
> >
> > think of an admin writing a quick script for intrusion detection
> > (find / -exec md5sum {} \; >/tmp/need-no-tripwire) and forgetting to
> > exclude /dev, /sys or /proc appropriately..
> > think of someone exporting "/" via samba (readonly) and then navigating
> > trough the /dev directory
> >
> > stupid?
> > i don`t think so.i have seen worse things.. :)
> >
> > should someone get punished by an accidental system reboot and should he
> > need to spend his time on this to investigate why this happens?
> >
> > i`d wish there would be some fence around this or iTCO_wdt /dev/watchdog
> > not being active after a default desktop installation.
>
> There is.. it's called "root privileges".
>
> >
> > i`d be interested if i`m the only one who thinks this is strange/dangerous
> > behaviour.
> >
> > regards
> > roland
>
>
> --
> Robert Hancock Saskatoon, SK, Canada
> To email, remove "nospam" from [EMAIL PROTECTED]
> Home Page: http://www.roberthancock.com/
>
>
__
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://produkte.web.de/club/?mc=021131
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
System reboot triggered by just reading a device file....!?
good evening,
i stumbled over some funny issue when trying windirstat (like KDirStat) with
wine.
after running that tool for a while my system rebooted. i could reproduce this
with every run.
after some deep investigation (i thought i had stability issues with my system
and spent more than an hour on this) i found out, that the reboot is being
triggered by iTCO_wdt ( /dev/watchdog )
this is how to reproduce:
- be root
- cat /dev/watchdog or dd if=/dev/watchdog of=/dev/zero bs=1 count=1 or .
- wait one minute
*reboot*!
i have heard 2 opinions for now (contacted the author and also discussed on
wine-devel ) that this should be expected behaviour.
being sysadmin quite a while, i cannot believe that (accidentally) reading a
device file (being root or not - what does that matter) triggers a system
reboot.
ok - when i`m root , i shouldn`t do stupid things and be careful, but i thought
reading/crawling trough a filesystem (r/o, btw.) with some tool which is built
to do exactly this wasn`t so stupid - even from within wine.
think of an admin writing a quick script for intrusion detection (find /
-exec md5sum {} \; >/tmp/need-no-tripwire) and forgetting to exclude /dev, /sys
or /proc appropriately..
think of someone exporting "/" via samba (readonly) and then navigating trough
the /dev directory
stupid?
i don`t think so.i have seen worse things.. :)
should someone get punished by an accidental system reboot and should he need
to spend his time on this to investigate why this happens?
i`d wish there would be some fence around this or iTCO_wdt /dev/watchdog not
being active after a default desktop installation.
i`d be interested if i`m the only one who thinks this is strange/dangerous
behaviour.
regards
roland
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071=0066
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
System reboot triggered by just reading a device file....!?
good evening,
i stumbled over some funny issue when trying windirstat (like KDirStat) with
wine.
after running that tool for a while my system rebooted. i could reproduce this
with every run.
after some deep investigation (i thought i had stability issues with my system
and spent more than an hour on this) i found out, that the reboot is being
triggered by iTCO_wdt ( /dev/watchdog )
this is how to reproduce:
- be root
- cat /dev/watchdog or dd if=/dev/watchdog of=/dev/zero bs=1 count=1 or .
- wait one minute
*reboot*!
i have heard 2 opinions for now (contacted the author and also discussed on
wine-devel ) that this should be expected behaviour.
being sysadmin quite a while, i cannot believe that (accidentally) reading a
device file (being root or not - what does that matter) triggers a system
reboot.
ok - when i`m root , i shouldn`t do stupid things and be careful, but i thought
reading/crawling trough a filesystem (r/o, btw.) with some tool which is built
to do exactly this wasn`t so stupid - even from within wine.
think of an admin writing a quickdirty script for intrusion detection (find /
-exec md5sum {} \; /tmp/need-no-tripwire) and forgetting to exclude /dev, /sys
or /proc appropriately..
think of someone exporting / via samba (readonly) and then navigating trough
the /dev directory
stupid?
i don`t think so.i have seen worse things.. :)
should someone get punished by an accidental system reboot and should he need
to spend his time on this to investigate why this happens?
i`d wish there would be some fence around this or iTCO_wdt /dev/watchdog not
being active after a default desktop installation.
i`d be interested if i`m the only one who thinks this is strange/dangerous
behaviour.
regards
roland
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071distributionid=0066
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: System reboot triggered by just reading a device file....!?
There is.. it's called root privileges.
yes, true.
but - regardless of being a windows app or not - what if you want to take a
look on your system as a whole, especially when using some tool which
graphically shows how and where your diskspace is being used? if i let this
run from ordinary useraccount it would get lot`s of permission denied and
then it`s only telling half of the truth.
I'd say running pretty much anything through Wine as root is
not a good idea, a Windows app could hose the system without even
meaning to through exactly such things.
yes, true indeed. but maybe wine has an option to sandbox the windows app to do
only r/o access. if that feature doesn`t exist, (set r/o flag to dosdevices)
maybe it would be an useful addon.
but that`s OT here
-Ursprüngliche Nachricht-
Von: Robert Hancock [EMAIL PROTECTED]
Gesendet: 21.11.07 00:35:23
An: [EMAIL PROTECTED]
CC: linux-kernel@vger.kernel.org
Betreff: Re: System reboot triggered by just reading a device file!?
[EMAIL PROTECTED] wrote:
good evening,
i stumbled over some funny issue when trying windirstat (like KDirStat)
with wine.
after running that tool for a while my system rebooted. i could reproduce
this with every run.
after some deep investigation (i thought i had stability issues with my
system and spent more than an hour on this) i found out, that the reboot is
being triggered by iTCO_wdt ( /dev/watchdog )
this is how to reproduce:
- be root
- cat /dev/watchdog or dd if=/dev/watchdog of=/dev/zero bs=1 count=1 or
.
- wait one minute
*reboot*!
i have heard 2 opinions for now (contacted the author and also discussed on
wine-devel ) that this should be expected behaviour.
Yes, it is. It's a watchdog device, it's meant to reboot the machine if
whatever task is poking the watchdog dies.
being sysadmin quite a while, i cannot believe that (accidentally) reading
a device file (being root or not - what does that matter) triggers a system
reboot.
ok - when i`m root , i shouldn`t do stupid things and be careful, but i
thought reading/crawling trough a filesystem (r/o, btw.) with some tool
which is built to do exactly this wasn`t so stupid - even from within wine.
I would say that running a Windows tool that opens up and reads random
files, on the /dev directory tree, as root, probably does qualify as
stupid. I'd say running pretty much anything through Wine as root is
not a good idea, a Windows app could hose the system without even
meaning to through exactly such things.
think of an admin writing a quickdirty script for intrusion detection
(find / -exec md5sum {} \; /tmp/need-no-tripwire) and forgetting to
exclude /dev, /sys or /proc appropriately..
think of someone exporting / via samba (readonly) and then navigating
trough the /dev directory
stupid?
i don`t think so.i have seen worse things.. :)
should someone get punished by an accidental system reboot and should he
need to spend his time on this to investigate why this happens?
i`d wish there would be some fence around this or iTCO_wdt /dev/watchdog
not being active after a default desktop installation.
There is.. it's called root privileges.
i`d be interested if i`m the only one who thinks this is strange/dangerous
behaviour.
regards
roland
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
__
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://produkte.web.de/club/?mc=021131
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: distro specific kernels vs vanilla kernel and how to compare among each other
besides a web-browseable directory structure with all the single broken-out patches (which are typically part of src.rpm or similar) , i assume it would be good to put those patched and unpatched kernel sources online via lxr ? ( http://lxr.linux.no/ ) > -Ursprüngliche Nachricht- > Von: "Andi Kleen" <[EMAIL PROTECTED]> > Gesendet: 16.11.07 23:25:29 > An: [EMAIL PROTECTED] > CC: linux-kernel@vger.kernel.org > Betreff: Re: distro specific kernels vs vanilla kernel and how to compare > among each other > > [EMAIL PROTECTED] writes: > > > does somebody know if there is a website or a project for giving > > comfortable and deeper insight into what`s specific to distro`s kernels and > > what`s their difference to vanilla kernel ? > > > > i mean some way to have some transparancy to what different distro vendors > > add to vanilla kernel sources and thus turning it into their own specific > > version. > > There used to be such a page at kernelnewbies, but at some point it > disappeared. > > I agree it would be a useful resource. > > -Andi > _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: distro specific kernels vs vanilla kernel and how to compare
>I would also like to see something like this nice to get positive feedback, thanks :) >as some work I'm doing on >working some funny networking (unfortunately IT department don't have >common sense) across multiple distros. so if _you_ have common sense, it`s up to you alone to make your own life easier and you should try hard to change their mind. how can you make sure your code is good and stable if other`s don`t review it ? why should you constantly work on porting your code to the next kernel release ? even worse, you need to port it to different vendor specific kernels. that`s a real waste of time... please try changing their minds and if you need some help/arguments i`m sure there are people who can help you freeing the source ! ;) maybe you will find some at http://www.kroah.com/log/linux/ols_2006_keynote.html regards roland List: linux-kernel Subject:Re: distro specific kernels vs vanilla kernel and how to compare From: ewanm89 Date: 2007-11-17 5:17:56 Message-ID: 20071117051756.4b1d20da () ewanm89-laptop [Download message RAW] On Fri, 16 Nov 2007 23:25:27 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] writes: > > > does somebody know if there is a website or a project for giving > > comfortable and deeper insight into what`s specific to distro`s > > kernels and what`s their difference to vanilla kernel ? > > > > i mean some way to have some transparancy to what different distro > > vendors add to vanilla kernel sources and thus turning it into > > their own specific version. > > There used to be such a page at kernelnewbies, but at some point it > disappeared. > > I agree it would be a useful resource. > > -Andi > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ I would also like to see something like this, as some work I'm doing on working some funny networking (unfortunately IT department don't have common sense) across multiple distros. Tracking the kernel patche differences between the distros seems to be the hardest part (comparing them to find what's needed for all distros to work). -- Ewan Marshall (ewanm89) ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: distro specific kernels vs vanilla kernel and how to compare
I would also like to see something like this nice to get positive feedback, thanks :) as some work I'm doing on working some funny networking (unfortunately IT department don't have common sense) across multiple distros. so if _you_ have common sense, it`s up to you alone to make your own life easier and you should try hard to change their mind. how can you make sure your code is good and stable if other`s don`t review it ? why should you constantly work on porting your code to the next kernel release ? even worse, you need to port it to different vendor specific kernels. that`s a real waste of time... please try changing their minds and if you need some help/arguments i`m sure there are people who can help you freeing the source ! ;) maybe you will find some at http://www.kroah.com/log/linux/ols_2006_keynote.html regards roland List: linux-kernel Subject:Re: distro specific kernels vs vanilla kernel and how to compare From: ewanm89 ewanm89 () googlemail ! com Date: 2007-11-17 5:17:56 Message-ID: 20071117051756.4b1d20da () ewanm89-laptop [Download message RAW] On Fri, 16 Nov 2007 23:25:27 +0100 Andi Kleen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: does somebody know if there is a website or a project for giving comfortable and deeper insight into what`s specific to distro`s kernels and what`s their difference to vanilla kernel ? i mean some way to have some transparancy to what different distro vendors add to vanilla kernel sources and thus turning it into their own specific version. There used to be such a page at kernelnewbies, but at some point it disappeared. I agree it would be a useful resource. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I would also like to see something like this, as some work I'm doing on working some funny networking (unfortunately IT department don't have common sense) across multiple distros. Tracking the kernel patche differences between the distros seems to be the hardest part (comparing them to find what's needed for all distros to work). -- Ewan Marshall (ewanm89) ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: distro specific kernels vs vanilla kernel and how to compare among each other
besides a web-browseable directory structure with all the single broken-out patches (which are typically part of src.rpm or similar) , i assume it would be good to put those patched and unpatched kernel sources online via lxr ? ( http://lxr.linux.no/ ) -Ursprüngliche Nachricht- Von: Andi Kleen [EMAIL PROTECTED] Gesendet: 16.11.07 23:25:29 An: [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org Betreff: Re: distro specific kernels vs vanilla kernel and how to compare among each other [EMAIL PROTECTED] writes: does somebody know if there is a website or a project for giving comfortable and deeper insight into what`s specific to distro`s kernels and what`s their difference to vanilla kernel ? i mean some way to have some transparancy to what different distro vendors add to vanilla kernel sources and thus turning it into their own specific version. There used to be such a page at kernelnewbies, but at some point it disappeared. I agree it would be a useful resource. -Andi _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
distro specific kernels vs vanilla kernel and how to c ompare among each other
Hi ! does somebody know if there is a website or a project for giving comfortable and deeper insight into what`s specific to distro`s kernels and what`s their difference to vanilla kernel ? i mean some way to have some transparancy to what different distro vendors add to vanilla kernel sources and thus turning it into their own specific version. some simple version of this could be a simple browseable archive like this: Fedora8-Kernel-2.6.23.1-42.fc8/vanilla: insgesamt 44492 drwxr-xr-x 2 root root 4096 16. Nov 20:24 . drwxr-xr-x 4 root root12288 16. Nov 20:24 .. -rw-r--r-- 1 root root 45488158 10. Okt 00:50 linux-2.6.23.tar.bz2 -rw-r--r-- 1 root root 1412 12. Okt 20:58 patch-2.6.23.1.bz2 Fedora8-Kernel-2.6.23.1-42.fc8/patches: insgesamt 10688 drwxr-xr-x 2 root root 12288 16. Nov 20:24 . drwxr-xr-x 4 root root 12288 16. Nov 20:24 .. -rw-r--r-- 1 root root 18908 3. Aug 01:37 linux-2.6-devmem.patch -rw-r--r-- 1 root root 461 12. Sep 20:35 linux-2.6-drivers-ssb-debug-revision.patch -rw-r--r-- 1 root root 839 16. Okt 02:15 linux-2.6-drm-fix-i915-allocation.patch -rw-r--r-- 1 root root1235 22. Okt 22:49 linux-2.6-e1000-bad-csum-allow.patch -rw-r--r-- 1 root root 52318 22. Sep 13:45 linux-2.6-execshield.patch -rw-r--r-- 1 root root4361 9. Okt 07:18 linux-2.6-firewire-lockdep.patch lot`s of patches OpenSuSE_10.3-Kernel-2.6.22.5-31/vanilla: insgesamt 44120 drwxr-xr-x 2 root root 4096 16. Nov 20:02 . drwxr-xr-x 4 root root 4096 16. Nov 20:02 .. -rw-r--r-- 1 root root 45119878 22. Sep 16:23 linux-2.6.22.tar.bz2 OpenSuSE_10.3-Kernel-2.6.22.5-31/patches: insgesamt 10360 drwxr-xr-x 15 root root 4096 16. Nov 20:07 . drwxr-xr-x 4 root root 4096 16. Nov 20:02 .. drwxr-xr-x 2 root root 4096 16. Nov 20:04 patches.apparmor drwxr-xr-x 2 root root 12288 16. Nov 20:04 patches.arch drwxr-xr-x 2 root root 12288 16. Nov 20:04 patches.drivers drwxr-xr-x 2 root root 4096 16. Nov 20:05 patches.fixes drwxr-xr-x 2 root root 4096 16. Nov 20:05 patches.kernel.org -rw-r--r-- 1 root root 104687 22. Sep 16:23 supported.conf .even more patches if something like this doesn`t already exist - would it be useful to start such a project ? regards roland _ In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
distro specific kernels vs vanilla kernel and how to c ompare among each other
Hi ! does somebody know if there is a website or a project for giving comfortable and deeper insight into what`s specific to distro`s kernels and what`s their difference to vanilla kernel ? i mean some way to have some transparancy to what different distro vendors add to vanilla kernel sources and thus turning it into their own specific version. some simple version of this could be a simple browseable archive like this: Fedora8-Kernel-2.6.23.1-42.fc8/vanilla: insgesamt 44492 drwxr-xr-x 2 root root 4096 16. Nov 20:24 . drwxr-xr-x 4 root root12288 16. Nov 20:24 .. -rw-r--r-- 1 root root 45488158 10. Okt 00:50 linux-2.6.23.tar.bz2 -rw-r--r-- 1 root root 1412 12. Okt 20:58 patch-2.6.23.1.bz2 Fedora8-Kernel-2.6.23.1-42.fc8/patches: insgesamt 10688 drwxr-xr-x 2 root root 12288 16. Nov 20:24 . drwxr-xr-x 4 root root 12288 16. Nov 20:24 .. -rw-r--r-- 1 root root 18908 3. Aug 01:37 linux-2.6-devmem.patch -rw-r--r-- 1 root root 461 12. Sep 20:35 linux-2.6-drivers-ssb-debug-revision.patch -rw-r--r-- 1 root root 839 16. Okt 02:15 linux-2.6-drm-fix-i915-allocation.patch -rw-r--r-- 1 root root1235 22. Okt 22:49 linux-2.6-e1000-bad-csum-allow.patch -rw-r--r-- 1 root root 52318 22. Sep 13:45 linux-2.6-execshield.patch -rw-r--r-- 1 root root4361 9. Okt 07:18 linux-2.6-firewire-lockdep.patch lot`s of patches OpenSuSE_10.3-Kernel-2.6.22.5-31/vanilla: insgesamt 44120 drwxr-xr-x 2 root root 4096 16. Nov 20:02 . drwxr-xr-x 4 root root 4096 16. Nov 20:02 .. -rw-r--r-- 1 root root 45119878 22. Sep 16:23 linux-2.6.22.tar.bz2 OpenSuSE_10.3-Kernel-2.6.22.5-31/patches: insgesamt 10360 drwxr-xr-x 15 root root 4096 16. Nov 20:07 . drwxr-xr-x 4 root root 4096 16. Nov 20:02 .. drwxr-xr-x 2 root root 4096 16. Nov 20:04 patches.apparmor drwxr-xr-x 2 root root 12288 16. Nov 20:04 patches.arch drwxr-xr-x 2 root root 12288 16. Nov 20:04 patches.drivers drwxr-xr-x 2 root root 4096 16. Nov 20:05 patches.fixes drwxr-xr-x 2 root root 4096 16. Nov 20:05 patches.kernel.org -rw-r--r-- 1 root root 104687 22. Sep 16:23 supported.conf .even more patches if something like this doesn`t already exist - would it be useful to start such a project ? regards roland _ In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: build failure, missing libvdeplug.h?
Hello! I tried 2.6.24-rc1-git11 with "allmodconfig ARCH=um" today. this gave at least two errors - i needed to set CONFIG_SMP=n and CONFIG_UML_NET_VDE=n to make it compile. not sure if options should be set to "n" automatically or being fixed differently, but if there is something broken or some header file missing, from an "end-user`s" point of view errors like this may be hard to get around. it`s nothing against UML, it`s just the fact that i would expect "allmodconfig" or "allyesconfig" to work out of the box. one should be able to compile a kernel without the need to use google, imho. many automated cross-compile tests i have seen till now mostly show more broken than successful builds, as you can see at http://l4x.org/k , and issues like this don`t help making this better. minor issue, though.. regards roland On Mon, Oct 29, 2007 at 04:24:54PM +0100, Roel Kluin wrote: > CC arch/um/drivers/vde_user.o > /home/roel/dnld/src/kernel/git/linux-2.6/arch/um/drivers/vde_user.c:8:24: > error: \ > libvdeplug.h: No such file or directory > /home/roel/dnld/src/kernel/git/linux-2.6/arch/um/drivers/vde_user.c: In > function \ > 'vde_user_init': > /home/roel/dnld/src/kernel/git/linux-2.6/arch/um/drivers/vde_user.c:18: > error: \ > 'VDECONN' undeclared (first use in this function) > ... > > the file libvdeplug.h is missing and I can't find it neither in the tree or on > the net. 'git-grep VDECONN' shows that VDECONN isn't defined anywhere. This is an option which requires support on the host (in the form of vde being installed - pcap is another example of this). Jeff > Roel Kluin wrote: >> the file libvdeplug.h is missing > >> There is a reference to http://wiki.virtualsquare.org/index.php/Main_Page in >> the Kconfig (also added by this commit). >> After reverting this commit the build continues. possibly the header >> libvdeplug.h was forgotten? > > Sorry for answering myself, but apparently it can be found here: > > http://vde.sourceforge.net/ > > I think, however that there is a 'depends on' missing in kconfig - to prevent > build > failure? __ XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club! Jetzt testen! http://produkte.web.de/club/?mc=021130 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: build failure, missing libvdeplug.h?
Hello! I tried 2.6.24-rc1-git11 with allmodconfig ARCH=um today. this gave at least two errors - i needed to set CONFIG_SMP=n and CONFIG_UML_NET_VDE=n to make it compile. not sure if options should be set to n automatically or being fixed differently, but if there is something broken or some header file missing, from an end-user`s point of view errors like this may be hard to get around. it`s nothing against UML, it`s just the fact that i would expect allmodconfig or allyesconfig to work out of the box. one should be able to compile a kernel without the need to use google, imho. many automated cross-compile tests i have seen till now mostly show more broken than successful builds, as you can see at http://l4x.org/k , and issues like this don`t help making this better. minor issue, though.. regards roland On Mon, Oct 29, 2007 at 04:24:54PM +0100, Roel Kluin wrote: CC arch/um/drivers/vde_user.o /home/roel/dnld/src/kernel/git/linux-2.6/arch/um/drivers/vde_user.c:8:24: error: \ libvdeplug.h: No such file or directory /home/roel/dnld/src/kernel/git/linux-2.6/arch/um/drivers/vde_user.c: In function \ 'vde_user_init': /home/roel/dnld/src/kernel/git/linux-2.6/arch/um/drivers/vde_user.c:18: error: \ 'VDECONN' undeclared (first use in this function) ... the file libvdeplug.h is missing and I can't find it neither in the tree or on the net. 'git-grep VDECONN' shows that VDECONN isn't defined anywhere. This is an option which requires support on the host (in the form of vde being installed - pcap is another example of this). Jeff Roel Kluin wrote: the file libvdeplug.h is missing There is a reference to http://wiki.virtualsquare.org/index.php/Main_Page in the Kconfig (also added by this commit). After reverting this commit the build continues. possibly the header libvdeplug.h was forgotten? Sorry for answering myself, but apparently it can be found here: http://vde.sourceforge.net/ I think, however that there is a 'depends on' missing in kconfig - to prevent build failure? __ XXL-Speicher, PC-Virenschutz, Spartarife mehr: Nur im WEB.DE Club! Jetzt testen! http://produkte.web.de/club/?mc=021130 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE][RFC] PlugSched-6.5.1 for 2.6.22
>Having a framework for giving people the choice between different >solutions usually sounds good in theory, but in practice there's the >often underestimated high price of people using a different solution >instead of reporting a problem with one solution or people adding >features to only one of the solutions resulting in different solutions >having different features and bugs instead of one solution with all >features and bug fixes. > >So you should give a good technical explanation why it's not technically >possible or not desirable for one solution to work well for everyone. >From a user`s point of view, i like PlugSched. It gives the average or inexperienced user the ability to switch between different schedulers and it empowers him to compare between them easily. I like choice. Ok, it`s not good to have too much of that, but it`s always good to have at least one or two alternatives. No patch and no compile orgy for the end-user anymore - he can try if a different scheduler makes his stuttering audio go away or if his desktop-environment is more responsive with "itchysched" than with "scratchysched". Take this as a user`s vote for PlugSched. There are pluggable I/O schedulers in Linux for years now, there was that switch from AS to CFQ as the default - so please give us pluggable CPU schedulers, too ! :) roland ps: i trust you kernel developers know what you are doing, but if scares me a little bit, that some integral and living part like O(1) being ripped off and being replaced by something new. On Sun, Jul 15, 2007 at 10:47:51AM -0700, Li, Tong N wrote: > > On Thursday 12 July 2007 00:17, Al Boldi wrote: > > > > > Peter Williams wrote: > > >> > > >> Probably the last one now that CFS is in the main line :-(. > > > > > > What do you mean? A pluggable scheduler framework is indispensible > even > > in > > > the presence of CFS or SD. > > > > Indeed, and I hope it gets merged, giving people the chance to test > out > > different schedulers easily, without having to do patching, > de-patching, > > re-patching and blah blah blah. > > > > Yes, such a framework would be invaluable, especially given that > scheduling often has conflicting goals and different workloads have > different requirements. No single solution fits all. >... Having a framework for giving people the choice between different solutions usually sounds good in theory, but in practice there's the often underestimated high price of people using a different solution instead of reporting a problem with one solution or people adding features to only one of the solutions resulting in different solutions having different features and bugs instead of one solution with all features and bug fixes. So you should give a good technical explanation why it's not technically possible or not desirable for one solution to work well for everyone. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071=0066 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE][RFC] PlugSched-6.5.1 for 2.6.22
Having a framework for giving people the choice between different solutions usually sounds good in theory, but in practice there's the often underestimated high price of people using a different solution instead of reporting a problem with one solution or people adding features to only one of the solutions resulting in different solutions having different features and bugs instead of one solution with all features and bug fixes. So you should give a good technical explanation why it's not technically possible or not desirable for one solution to work well for everyone. From a user`s point of view, i like PlugSched. It gives the average or inexperienced user the ability to switch between different schedulers and it empowers him to compare between them easily. I like choice. Ok, it`s not good to have too much of that, but it`s always good to have at least one or two alternatives. No patch and no compile orgy for the end-user anymore - he can try if a different scheduler makes his stuttering audio go away or if his desktop-environment is more responsive with itchysched than with scratchysched. Take this as a user`s vote for PlugSched. There are pluggable I/O schedulers in Linux for years now, there was that switch from AS to CFQ as the default - so please give us pluggable CPU schedulers, too ! :) roland ps: i trust you kernel developers know what you are doing, but if scares me a little bit, that some integral and living part like O(1) being ripped off and being replaced by something new. On Sun, Jul 15, 2007 at 10:47:51AM -0700, Li, Tong N wrote: On Thursday 12 July 2007 00:17, Al Boldi wrote: Peter Williams wrote: Probably the last one now that CFS is in the main line :-(. What do you mean? A pluggable scheduler framework is indispensible even in the presence of CFS or SD. Indeed, and I hope it gets merged, giving people the chance to test out different schedulers easily, without having to do patching, de-patching, re-patching and blah blah blah. Yes, such a framework would be invaluable, especially given that scheduling often has conflicting goals and different workloads have different requirements. No single solution fits all. ... Having a framework for giving people the choice between different solutions usually sounds good in theory, but in practice there's the often underestimated high price of people using a different solution instead of reporting a problem with one solution or people adding features to only one of the solutions resulting in different solutions having different features and bugs instead of one solution with all features and bug fixes. So you should give a good technical explanation why it's not technically possible or not desirable for one solution to work well for everyone. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reiser @ wired.com
> GAFL. "Gossip fans" are over there at splashsnot; now bugger off and do not > crosspost. that was just meant ironic. now i feel like a troll. i`m not a tabloid reporter and also not related to wired.com, i just thought there is more than one person on this list who is very interested in "what`s up with Hans". i think i will avoid posting non-technical information to technical mailinglists in the future > -Ursprüngliche Nachricht- > Von: Al Viro <[EMAIL PROTECTED]> > Gesendet: 06.07.07 09:57:47 > An: [EMAIL PROTECTED] > CC: linux-kernel@vger.kernel.org > Betreff: Re: Reiser @ wired.com > > On Fri, Jul 06, 2007 at 09:42:52AM +0200, [EMAIL PROTECTED] wrote: > > Hi ! > > > > it seems that it hasn`t brought up here yet, so I`d like to let you know > > that there is some long Reiser-Story at WIRED MAGAZINE: ISSUE 15.07. > > > > For all you gossip fans ;) or for those who want to have some more "in > > depth" information obout the incident or the person Hans Reiser himself - > > it`s at: > > > > http://www.wired.com/techbiz/people/magazine/15-07/ff_hansreiser > > > > scary. > > nearly sounds like stuff for a movie for me.. > > GAFL. "Gossip fans" are over there at splashsnot; now bugger off and do not > crosspost. > ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reiser @ wired.com
Hi ! it seems that it hasn`t brought up here yet, so I`d like to let you know that there is some long Reiser-Story at WIRED MAGAZINE: ISSUE 15.07. For all you gossip fans ;) or for those who want to have some more "in depth" information obout the incident or the person Hans Reiser himself - it`s at: http://www.wired.com/techbiz/people/magazine/15-07/ff_hansreiser scary. nearly sounds like stuff for a movie for me.. roland ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reiser @ wired.com
Hi ! it seems that it hasn`t brought up here yet, so I`d like to let you know that there is some long Reiser-Story at WIRED MAGAZINE: ISSUE 15.07. For all you gossip fans ;) or for those who want to have some more in depth information obout the incident or the person Hans Reiser himself - it`s at: http://www.wired.com/techbiz/people/magazine/15-07/ff_hansreiser scary. nearly sounds like stuff for a movie for me.. roland ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reiser @ wired.com
GAFL. Gossip fans are over there at splashsnot; now bugger off and do not crosspost. that was just meant ironic. now i feel like a troll. i`m not a tabloid reporter and also not related to wired.com, i just thought there is more than one person on this list who is very interested in what`s up with Hans. i think i will avoid posting non-technical information to technical mailinglists in the future -Ursprüngliche Nachricht- Von: Al Viro [EMAIL PROTECTED] Gesendet: 06.07.07 09:57:47 An: [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org Betreff: Re: Reiser @ wired.com On Fri, Jul 06, 2007 at 09:42:52AM +0200, [EMAIL PROTECTED] wrote: Hi ! it seems that it hasn`t brought up here yet, so I`d like to let you know that there is some long Reiser-Story at WIRED MAGAZINE: ISSUE 15.07. For all you gossip fans ;) or for those who want to have some more in depth information obout the incident or the person Hans Reiser himself - it`s at: http://www.wired.com/techbiz/people/magazine/15-07/ff_hansreiser scary. nearly sounds like stuff for a movie for me.. GAFL. Gossip fans are over there at splashsnot; now bugger off and do not crosspost. ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
