Re: Resizeable PCI BAR support V5
Hello Christian, after (long ;-)) vacation, injured wife (bad lumbago/luckily NO disc prolapse) on 2cond day @ our target, our daughter's 12th birthday, school start for both kids and mostly dad work I'm back... Do you have a V6 handy. Will do my fingers dirty if no Intel guy beats me at it. Greetings, Dieter Am 30.06.2017 14:55, schrieb Christian König: Hi Dieter, thanks a lot for testing that. But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), PCIe 2.0, 24 GB is to old for this stuff... Well, actually you only need to figure out how to enable a PCIe window above the 4GB limit. Could be that the BIOS supports this with the ACPI tables (totally unlikely) or you could try to dig up the Northbridge documentation for this CPU from Intel and use my patch for the AMD CPUs as blueprint how to do this on an Intel CPU as well. Fact is you GFX hardware is perfectly capable of doing this, it's just that the BIOS/Motherboard didn't enabled a PCIe window per default to avoid problems with 32bit OSes. Regards, Christian. Am 30.06.2017 um 01:51 schrieb Dieter Nützel: Hello Christian, I've running this since you've sent it on-top of amd-staging-4.11. But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), PCIe 2.0, 24 GB is to old for this stuff... [1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 0x-0x0003 64bit] (contains BAR0 for 16 VFs) [1.066489] pci :05:00.0: VF(n) BAR2 space: [mem 0x-0x003f 64bit] (contains BAR2 for 16 VFs) [1.121656] pci :00:1c.0: BAR 15: assigned [mem 0x8000-0x801f 64bit pref] [1.121659] pci :00:1c.6: BAR 15: assigned [mem 0x8020-0x803f 64bit pref] [1.121662] pci :01:00.0: BAR 6: assigned [mem 0xb012-0xb013 pref] [1.121681] pci :05:00.0: BAR 6: assigned [mem 0xb028-0xb02f pref] [1.121683] pci :05:00.0: BAR 9: no space for [mem size 0x0040 64bit] [1.121684] pci :05:00.0: BAR 9: failed to assign [mem size 0x0040 64bit] [1.121685] pci :05:00.0: BAR 7: no space for [mem size 0x0004 64bit] [1.121687] pci :05:00.0: BAR 7: failed to assign [mem size 0x0004 64bit] [3.874180] amdgpu :01:00.0: BAR 0: releasing [mem 0xc000-0xcfff 64bit pref] [3.874182] amdgpu :01:00.0: BAR 2: releasing [mem 0xb040-0xb05f 64bit pref] [3.874198] pcieport :00:03.0: BAR 15: releasing [mem 0xb040-0xcfff 64bit pref] [3.874215] pcieport :00:03.0: BAR 15: no space for [mem size 0x3 64bit pref] [3.874217] pcieport :00:03.0: BAR 15: failed to assign [mem size 0x3 64bit pref] [3.874221] amdgpu :01:00.0: BAR 0: no space for [mem size 0x2 64bit pref] [3.874223] amdgpu :01:00.0: BAR 0: failed to assign [mem size 0x2 64bit pref] [3.874226] amdgpu :01:00.0: BAR 2: no space for [mem size 0x0020 64bit pref] [3.874227] amdgpu :01:00.0: BAR 2: failed to assign [mem size 0x0020 64bit pref] [3.874258] [drm] Not enough PCI address space for a large BAR. [3.874261] amdgpu :01:00.0: BAR 0: assigned [mem 0xc000-0xcfff 64bit pref] [3.874269] amdgpu :01:00.0: BAR 2: assigned [mem 0xb040-0xb05f 64bit pref] [3.874288] [drm] Detected VRAM RAM=8192M, BAR=256M Anyway rebase for current amd-staging-4.11 needed. Find attached dmesg-amd-staging-4.11-1.g7262353-default+.log.xz Greetings, Dieter Am 09.06.2017 10:59, schrieb Christian König: Hi everyone, This is the fith incarnation of this set of patches. It enables device drivers to resize and most likely also relocate the PCI BAR of devices they manage to allow the CPU to access all of the device local memory at once. This is very useful for GFX device drivers where the default PCI BAR is only about 256MB in size for compatibility reasons, but the device easily have multiple gigabyte of local memory. Some changes since V4: 1. Rebased on 4.11. 2. added the rb from Andy Shevchenko to patches which look complete now. 3. Move releasing the BAR and reallocating it on error to the driver side. 4. Add amdgpu support for GMC V6 hardware generation as well. Please review and/or comment, Christian. ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Resizeable PCI BAR support V5
Hello Christian, after (long ;-)) vacation, injured wife (bad lumbago/luckily NO disc prolapse) on 2cond day @ our target, our daughter's 12th birthday, school start for both kids and mostly dad work I'm back... Do you have a V6 handy. Will do my fingers dirty if no Intel guy beats me at it. Greetings, Dieter Am 30.06.2017 14:55, schrieb Christian König: Hi Dieter, thanks a lot for testing that. But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), PCIe 2.0, 24 GB is to old for this stuff... Well, actually you only need to figure out how to enable a PCIe window above the 4GB limit. Could be that the BIOS supports this with the ACPI tables (totally unlikely) or you could try to dig up the Northbridge documentation for this CPU from Intel and use my patch for the AMD CPUs as blueprint how to do this on an Intel CPU as well. Fact is you GFX hardware is perfectly capable of doing this, it's just that the BIOS/Motherboard didn't enabled a PCIe window per default to avoid problems with 32bit OSes. Regards, Christian. Am 30.06.2017 um 01:51 schrieb Dieter Nützel: Hello Christian, I've running this since you've sent it on-top of amd-staging-4.11. But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), PCIe 2.0, 24 GB is to old for this stuff... [1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 0x-0x0003 64bit] (contains BAR0 for 16 VFs) [1.066489] pci :05:00.0: VF(n) BAR2 space: [mem 0x-0x003f 64bit] (contains BAR2 for 16 VFs) [1.121656] pci :00:1c.0: BAR 15: assigned [mem 0x8000-0x801f 64bit pref] [1.121659] pci :00:1c.6: BAR 15: assigned [mem 0x8020-0x803f 64bit pref] [1.121662] pci :01:00.0: BAR 6: assigned [mem 0xb012-0xb013 pref] [1.121681] pci :05:00.0: BAR 6: assigned [mem 0xb028-0xb02f pref] [1.121683] pci :05:00.0: BAR 9: no space for [mem size 0x0040 64bit] [1.121684] pci :05:00.0: BAR 9: failed to assign [mem size 0x0040 64bit] [1.121685] pci :05:00.0: BAR 7: no space for [mem size 0x0004 64bit] [1.121687] pci :05:00.0: BAR 7: failed to assign [mem size 0x0004 64bit] [3.874180] amdgpu :01:00.0: BAR 0: releasing [mem 0xc000-0xcfff 64bit pref] [3.874182] amdgpu :01:00.0: BAR 2: releasing [mem 0xb040-0xb05f 64bit pref] [3.874198] pcieport :00:03.0: BAR 15: releasing [mem 0xb040-0xcfff 64bit pref] [3.874215] pcieport :00:03.0: BAR 15: no space for [mem size 0x3 64bit pref] [3.874217] pcieport :00:03.0: BAR 15: failed to assign [mem size 0x3 64bit pref] [3.874221] amdgpu :01:00.0: BAR 0: no space for [mem size 0x2 64bit pref] [3.874223] amdgpu :01:00.0: BAR 0: failed to assign [mem size 0x2 64bit pref] [3.874226] amdgpu :01:00.0: BAR 2: no space for [mem size 0x0020 64bit pref] [3.874227] amdgpu :01:00.0: BAR 2: failed to assign [mem size 0x0020 64bit pref] [3.874258] [drm] Not enough PCI address space for a large BAR. [3.874261] amdgpu :01:00.0: BAR 0: assigned [mem 0xc000-0xcfff 64bit pref] [3.874269] amdgpu :01:00.0: BAR 2: assigned [mem 0xb040-0xb05f 64bit pref] [3.874288] [drm] Detected VRAM RAM=8192M, BAR=256M Anyway rebase for current amd-staging-4.11 needed. Find attached dmesg-amd-staging-4.11-1.g7262353-default+.log.xz Greetings, Dieter Am 09.06.2017 10:59, schrieb Christian König: Hi everyone, This is the fith incarnation of this set of patches. It enables device drivers to resize and most likely also relocate the PCI BAR of devices they manage to allow the CPU to access all of the device local memory at once. This is very useful for GFX device drivers where the default PCI BAR is only about 256MB in size for compatibility reasons, but the device easily have multiple gigabyte of local memory. Some changes since V4: 1. Rebased on 4.11. 2. added the rb from Andy Shevchenko to patches which look complete now. 3. Move releasing the BAR and reallocating it on error to the driver side. 4. Add amdgpu support for GMC V6 hardware generation as well. Please review and/or comment, Christian. ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Resizeable PCI BAR support V5
Hello Christian, I've running this since you've sent it on-top of amd-staging-4.11. But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), PCIe 2.0, 24 GB is to old for this stuff... [1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 0x-0x0003 64bit] (contains BAR0 for 16 VFs) [1.066489] pci :05:00.0: VF(n) BAR2 space: [mem 0x-0x003f 64bit] (contains BAR2 for 16 VFs) [1.121656] pci :00:1c.0: BAR 15: assigned [mem 0x8000-0x801f 64bit pref] [1.121659] pci :00:1c.6: BAR 15: assigned [mem 0x8020-0x803f 64bit pref] [1.121662] pci :01:00.0: BAR 6: assigned [mem 0xb012-0xb013 pref] [1.121681] pci :05:00.0: BAR 6: assigned [mem 0xb028-0xb02f pref] [1.121683] pci :05:00.0: BAR 9: no space for [mem size 0x0040 64bit] [1.121684] pci :05:00.0: BAR 9: failed to assign [mem size 0x0040 64bit] [1.121685] pci :05:00.0: BAR 7: no space for [mem size 0x0004 64bit] [1.121687] pci :05:00.0: BAR 7: failed to assign [mem size 0x0004 64bit] [3.874180] amdgpu :01:00.0: BAR 0: releasing [mem 0xc000-0xcfff 64bit pref] [3.874182] amdgpu :01:00.0: BAR 2: releasing [mem 0xb040-0xb05f 64bit pref] [3.874198] pcieport :00:03.0: BAR 15: releasing [mem 0xb040-0xcfff 64bit pref] [3.874215] pcieport :00:03.0: BAR 15: no space for [mem size 0x3 64bit pref] [3.874217] pcieport :00:03.0: BAR 15: failed to assign [mem size 0x3 64bit pref] [3.874221] amdgpu :01:00.0: BAR 0: no space for [mem size 0x2 64bit pref] [3.874223] amdgpu :01:00.0: BAR 0: failed to assign [mem size 0x2 64bit pref] [3.874226] amdgpu :01:00.0: BAR 2: no space for [mem size 0x0020 64bit pref] [3.874227] amdgpu :01:00.0: BAR 2: failed to assign [mem size 0x0020 64bit pref] [3.874258] [drm] Not enough PCI address space for a large BAR. [3.874261] amdgpu :01:00.0: BAR 0: assigned [mem 0xc000-0xcfff 64bit pref] [3.874269] amdgpu :01:00.0: BAR 2: assigned [mem 0xb040-0xb05f 64bit pref] [3.874288] [drm] Detected VRAM RAM=8192M, BAR=256M Anyway rebase for current amd-staging-4.11 needed. Find attached dmesg-amd-staging-4.11-1.g7262353-default+.log.xz Greetings, Dieter Am 09.06.2017 10:59, schrieb Christian König: Hi everyone, This is the fith incarnation of this set of patches. It enables device drivers to resize and most likely also relocate the PCI BAR of devices they manage to allow the CPU to access all of the device local memory at once. This is very useful for GFX device drivers where the default PCI BAR is only about 256MB in size for compatibility reasons, but the device easily have multiple gigabyte of local memory. Some changes since V4: 1. Rebased on 4.11. 2. added the rb from Andy Shevchenko to patches which look complete now. 3. Move releasing the BAR and reallocating it on error to the driver side. 4. Add amdgpu support for GMC V6 hardware generation as well. Please review and/or comment, Christian. ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel dmesg-amd-staging-4.11-1.g7262353-default+.log.xz Description: application/xz
Re: Resizeable PCI BAR support V5
Hello Christian, I've running this since you've sent it on-top of amd-staging-4.11. But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), PCIe 2.0, 24 GB is to old for this stuff... [1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 0x-0x0003 64bit] (contains BAR0 for 16 VFs) [1.066489] pci :05:00.0: VF(n) BAR2 space: [mem 0x-0x003f 64bit] (contains BAR2 for 16 VFs) [1.121656] pci :00:1c.0: BAR 15: assigned [mem 0x8000-0x801f 64bit pref] [1.121659] pci :00:1c.6: BAR 15: assigned [mem 0x8020-0x803f 64bit pref] [1.121662] pci :01:00.0: BAR 6: assigned [mem 0xb012-0xb013 pref] [1.121681] pci :05:00.0: BAR 6: assigned [mem 0xb028-0xb02f pref] [1.121683] pci :05:00.0: BAR 9: no space for [mem size 0x0040 64bit] [1.121684] pci :05:00.0: BAR 9: failed to assign [mem size 0x0040 64bit] [1.121685] pci :05:00.0: BAR 7: no space for [mem size 0x0004 64bit] [1.121687] pci :05:00.0: BAR 7: failed to assign [mem size 0x0004 64bit] [3.874180] amdgpu :01:00.0: BAR 0: releasing [mem 0xc000-0xcfff 64bit pref] [3.874182] amdgpu :01:00.0: BAR 2: releasing [mem 0xb040-0xb05f 64bit pref] [3.874198] pcieport :00:03.0: BAR 15: releasing [mem 0xb040-0xcfff 64bit pref] [3.874215] pcieport :00:03.0: BAR 15: no space for [mem size 0x3 64bit pref] [3.874217] pcieport :00:03.0: BAR 15: failed to assign [mem size 0x3 64bit pref] [3.874221] amdgpu :01:00.0: BAR 0: no space for [mem size 0x2 64bit pref] [3.874223] amdgpu :01:00.0: BAR 0: failed to assign [mem size 0x2 64bit pref] [3.874226] amdgpu :01:00.0: BAR 2: no space for [mem size 0x0020 64bit pref] [3.874227] amdgpu :01:00.0: BAR 2: failed to assign [mem size 0x0020 64bit pref] [3.874258] [drm] Not enough PCI address space for a large BAR. [3.874261] amdgpu :01:00.0: BAR 0: assigned [mem 0xc000-0xcfff 64bit pref] [3.874269] amdgpu :01:00.0: BAR 2: assigned [mem 0xb040-0xb05f 64bit pref] [3.874288] [drm] Detected VRAM RAM=8192M, BAR=256M Anyway rebase for current amd-staging-4.11 needed. Find attached dmesg-amd-staging-4.11-1.g7262353-default+.log.xz Greetings, Dieter Am 09.06.2017 10:59, schrieb Christian König: Hi everyone, This is the fith incarnation of this set of patches. It enables device drivers to resize and most likely also relocate the PCI BAR of devices they manage to allow the CPU to access all of the device local memory at once. This is very useful for GFX device drivers where the default PCI BAR is only about 256MB in size for compatibility reasons, but the device easily have multiple gigabyte of local memory. Some changes since V4: 1. Rebased on 4.11. 2. added the rb from Andy Shevchenko to patches which look complete now. 3. Move releasing the BAR and reallocating it on error to the driver side. 4. Add amdgpu support for GMC V6 hardware generation as well. Please review and/or comment, Christian. ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel dmesg-amd-staging-4.11-1.g7262353-default+.log.xz Description: application/xz
Re: [git pull] drm radeon/nouveau/core fixes
Am 19.09.2013 04:07, schrieb Dave Airlie: Hi Linus, mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix for AST driver. Dave. The following changes since commit 01172772c7c973debf5b4881fcb9463891ea97ec: drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 928c2f0c006bf7f381f58af2b2786d2a858ae311: drm/fb-helper: don't sleep for screen unblank when an oops is in progress (2013-09-19 11:54:34 +1000) [-] Christian König (3): drm/radeon: remove stale radeon_fence_retire tracepoint drm/radeon: add command submission tracepoint drm/radeon: avoid UVD corruptions on AGP cards Alex, I think your PCIE AGP (radeon.agpmode=-1) UVD fix is missing, here. Thanks for working UVD and dpm on mostly all asics! -Dieter -- 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: [git pull] drm radeon/nouveau/core fixes
Am 19.09.2013 04:07, schrieb Dave Airlie: Hi Linus, mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix for AST driver. Dave. The following changes since commit 01172772c7c973debf5b4881fcb9463891ea97ec: drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 928c2f0c006bf7f381f58af2b2786d2a858ae311: drm/fb-helper: don't sleep for screen unblank when an oops is in progress (2013-09-19 11:54:34 +1000) [-] Christian König (3): drm/radeon: remove stale radeon_fence_retire tracepoint drm/radeon: add command submission tracepoint drm/radeon: avoid UVD corruptions on AGP cards Alex, I think your PCIE AGP (radeon.agpmode=-1) UVD fix is missing, here. Thanks for working UVD and dpm on mostly all asics! -Dieter -- 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: [regression] openSUSE 12.2 stable kernel 3.7.8-1 big USB 2.0 slowdown
Am 2013-02-19 10:16, schrieb Jiri Slaby: On 02/19/2013 03:56 AM, Alan Stern wrote: On Mon, 18 Feb 2013, Jiri Slaby wrote: On 02/18/2013 06:25 AM, Anja Nützel wrote: Maybe it startet with 3.7.7. I could copy several MB onto my USB 2.0 sticks with 3.7.6. (I think). Even with full speed. With openSUSE 12.2 DVD (kernel 3.4.x) it works OK, too. Now it degrates to 12 mbits (full-speed USB only). This is an upstream 3.7.7 stable regression, I think. Some of these patches perhaps: d7da098 USB: EHCI: fix for leaking isochronous data caa891a USB: storage: optimize to match the Huawei USB storage devices and support new switch command 08b4bfd USB: storage: Define a new macro for USB storage match rules 390077b usb: Using correct way to clear usb3.0 device's remote wakeup feature. 93dffb7 USB: EHCI: fix bug in scheduling periodic split transfers bf79379 USB: EHCI: fix timer bug affecting port resume d01875f USB: EHCI: unlink one async QH at a time 269ef9f USB: EHCI: remove ASS/PSS polling timeout Alan, any ideas? A lot of people have reported problems caused by the last one (269ef9f). I haven't had time to investigate yet (just got back from vacation). I reverted that one in: http://labs.suse.cz/jslaby/bug-804367/ Anja, could you test that kernel? "Anja's" kernel (your kernel-desktop-3.7.9-0.i686.rpm) works OK! openSUSE stable (kernel-desktop-3.7.9-1.1) of course NOT. Only little thing KDE-Infozentrum Version 4.10.00 "release 547" Unter KDE 4.10.00 "release 550" do not show all USB devices correctly. Sonja /Pakete# lsusb -t 4-1:1.0: No such file or directory /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=vend., Driver=, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M |__ Port 2: Dev 5, If 0, Class=stor., Driver=usb-storage, 480M |__ Port 3: Dev 4, If 0, Class=stor., Driver=usb-storage, 480M |__ Port 8: Dev 3, If 0, Class=stor., Driver=usb-storage, 480M Sonja /Pakete# lsusb Bus 001 Device 005: ID 0951:1607 Kingston Technology DataTraveler 100 Bus 001 Device 004: ID 058f:6387 Alcor Micro Corp. Transcend JetFlash Flash Drive Bus 001 Device 003: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer Bus 004 Device 002: ID 04a9:220d Canon, Inc. CanoScan N670U/N676U/LiDE 20 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Thank very much! Anja & Dieter -- 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: [regression] openSUSE 12.2 stable kernel 3.7.8-1 big USB 2.0 slowdown
Am 2013-02-19 10:16, schrieb Jiri Slaby: On 02/19/2013 03:56 AM, Alan Stern wrote: On Mon, 18 Feb 2013, Jiri Slaby wrote: On 02/18/2013 06:25 AM, Anja Nützel wrote: Maybe it startet with 3.7.7. I could copy several MB onto my USB 2.0 sticks with 3.7.6. (I think). Even with full speed. With openSUSE 12.2 DVD (kernel 3.4.x) it works OK, too. Now it degrates to 12 mbits (full-speed USB only). This is an upstream 3.7.7 stable regression, I think. Some of these patches perhaps: d7da098 USB: EHCI: fix for leaking isochronous data caa891a USB: storage: optimize to match the Huawei USB storage devices and support new switch command 08b4bfd USB: storage: Define a new macro for USB storage match rules 390077b usb: Using correct way to clear usb3.0 device's remote wakeup feature. 93dffb7 USB: EHCI: fix bug in scheduling periodic split transfers bf79379 USB: EHCI: fix timer bug affecting port resume d01875f USB: EHCI: unlink one async QH at a time 269ef9f USB: EHCI: remove ASS/PSS polling timeout Alan, any ideas? A lot of people have reported problems caused by the last one (269ef9f). I haven't had time to investigate yet (just got back from vacation). I reverted that one in: http://labs.suse.cz/jslaby/bug-804367/ Anja, could you test that kernel? Anja's kernel (your kernel-desktop-3.7.9-0.i686.rpm) works OK! openSUSE stable (kernel-desktop-3.7.9-1.1) of course NOT. Only little thing KDE-Infozentrum Version 4.10.00 release 547 Unter KDE 4.10.00 release 550 do not show all USB devices correctly. Sonja /Pakete# lsusb -t 4-1:1.0: No such file or directory /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=vend., Driver=, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M |__ Port 2: Dev 5, If 0, Class=stor., Driver=usb-storage, 480M |__ Port 3: Dev 4, If 0, Class=stor., Driver=usb-storage, 480M |__ Port 8: Dev 3, If 0, Class=stor., Driver=usb-storage, 480M Sonja /Pakete# lsusb Bus 001 Device 005: ID 0951:1607 Kingston Technology DataTraveler 100 Bus 001 Device 004: ID 058f:6387 Alcor Micro Corp. Transcend JetFlash Flash Drive Bus 001 Device 003: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer Bus 004 Device 002: ID 04a9:220d Canon, Inc. CanoScan N670U/N676U/LiDE 20 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Thank very much! Anja Dieter -- 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: XFS corruption during power-blackout
Am Dienstag, 5. Juli 2005 20:10 schrieb Sonny Rao:
> On Tue, Jul 05, 2005 at 08:25:11PM +0300, Al Boldi wrote:
> > Sonny Rao wrote: {
> >
> > > > >On Wed, Jun 29, 2005 at 07:53:09AM +0300, Al Boldi wrote:
> > > > >>What I found were 4 things in the dest dir:
> > > > >>1. Missing Dirs,Files. That's OK.
> > > > >>2. Files of size 0. That's acceptable.
> > > > >>3. Corrupted Files. That's unacceptable.
> > > > >>4. Corrupted Files with original fingerprint. That's ABSOLUTELY
> > > > >>unacceptable.
> > >
> > > 2. Moral of the story is: What's ext3 doing the others aren't?
> >
> > Ext3 has stronger guaranties than basic filesystem consistency.
> > I.e. in ordered mode, file data is always written before metadata, so the
> > worst that could happen is a growing file's new data is written but the
> > metadata isn't updated before a power failure... so the new writes
> > wouldn't be seen afterwards.
> >
> > }
> >
> > Sonny,
> > Thanks for you input!
> > Is there an option in XFS,ReiserFS,JFS to enable ordered mode?
>
> I beleive in newer 2.6 kernels that Reiser has ordered mode (IIRC, courtesy
> of Chris Mason),
And SuSE, ack.
ftp://ftp.suse.com/pub/people/mason/patches/data-logging
They are around some time ;-)
> but XFS and JFS do not support it. I seem to remember
> Shaggy (JFS maintainer) saying in older 2.4 kernels he tried to write
> file data before metadata but had to change that behavior in 2.6, not
> really sure why or anything beyond that.
Greetings,
Dieter
--
Dieter Nützel
@home:
-
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: XFS corruption during power-blackout
Am Dienstag, 5. Juli 2005 20:10 schrieb Sonny Rao:
On Tue, Jul 05, 2005 at 08:25:11PM +0300, Al Boldi wrote:
Sonny Rao wrote: {
On Wed, Jun 29, 2005 at 07:53:09AM +0300, Al Boldi wrote:
What I found were 4 things in the dest dir:
1. Missing Dirs,Files. That's OK.
2. Files of size 0. That's acceptable.
3. Corrupted Files. That's unacceptable.
4. Corrupted Files with original fingerprint. That's ABSOLUTELY
unacceptable.
2. Moral of the story is: What's ext3 doing the others aren't?
Ext3 has stronger guaranties than basic filesystem consistency.
I.e. in ordered mode, file data is always written before metadata, so the
worst that could happen is a growing file's new data is written but the
metadata isn't updated before a power failure... so the new writes
wouldn't be seen afterwards.
}
Sonny,
Thanks for you input!
Is there an option in XFS,ReiserFS,JFS to enable ordered mode?
I beleive in newer 2.6 kernels that Reiser has ordered mode (IIRC, courtesy
of Chris Mason),
And SuSE, ack.
ftp://ftp.suse.com/pub/people/mason/patches/data-logging
They are around some time ;-)
but XFS and JFS do not support it. I seem to remember
Shaggy (JFS maintainer) saying in older 2.4 kernels he tried to write
file data before metadata but had to change that behavior in 2.6, not
really sure why or anything beyond that.
Greetings,
Dieter
--
Dieter Nützel
@home: Dieter () nuetzel-hh ! de
-
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/
[reiserfs-list] Re: [PATCH] Preemption Latency Measurement Tool
Am Sonntag, 23. September 2001 05:14 schrieb george anzinger: > Robert Love wrote: > > On Sat, 2001-09-22 at 19:40, safemode wrote: > > > ok. The preemption patch helps realtime applications in linux be a > > > little more close to realtime. I understand that. But your mp3 player > > > shouldn't need root permission or renicing or realtime priority flags > > > to play mp3s. > > > > It doesn't, it needs them to play with a dbench 32 running in the > > background. This isn't nessecarily acceptable, either, but it is a > > difference. > > > > Note one thing the preemption patch does is really make `realtime' apps > > accel. Without it, regardless of the priority of the application, the > > app can be starved due to something in kernel mode. Now it can't, and > > since said application is high priority, it will get the CPU when it > > wants it. > > > > This is not to say the preemption patch is no good if you don't run > > stuff at realtime -- I don't (who uses nice, anyhow? :>), and I notice > > a difference. > > > > > To > > > test how well the latency patches are working you should be running > > > things all at the same priority. The main issue people are having with > > > skipping mp3s is not in the decoding of the mp3 or in the retrieving of > > > the file, it's in the playing in the soundcard. That's being affected > > > by dbench flooding the system with irq requests. I'm inclined to > > > believe it's irq requests because the _only_ time i have problems with > > > mp3s (and i dont change priority levels) is when A. i do a cdparanoia > > > -Z -B "1-"or dbench 32. I bet if someone did these tests on scsi > > > hardware with the latency patch, they'd find much better results than > > > us users of ide devices. > > > > The skips are really big to be irq requests, although perhaps you are > > right in that the handling of the irq (we disable preemption during > > irq_off, of course, but also during bottom half execution) is the > > problem. > > > > However, I am more inclined to believe it is something else. All these > > long held locks can indeed be the problem. > > > > I am on an all UW2 SCSI system, and I have no major blips playing during > > a `dbench 16' (never ran 32). However, many other users (Dieter, I > > believe) are on a SCSI system too. > > Dieter, could you post your .config file? It might have a clue or two. Here it comes. Good night ;-) -Dieter BTW I have very good results (not the hiccup) for 2.4.10-pre14 + ReiserFS journal.c-2-patch from Chris config.bz2 Description: BZip2 compressed data
[reiserfs-list] Re: [PATCH] Preemption Latency Measurement Tool
Am Sonntag, 23. September 2001 05:14 schrieb george anzinger: Robert Love wrote: On Sat, 2001-09-22 at 19:40, safemode wrote: ok. The preemption patch helps realtime applications in linux be a little more close to realtime. I understand that. But your mp3 player shouldn't need root permission or renicing or realtime priority flags to play mp3s. It doesn't, it needs them to play with a dbench 32 running in the background. This isn't nessecarily acceptable, either, but it is a difference. Note one thing the preemption patch does is really make `realtime' apps accel. Without it, regardless of the priority of the application, the app can be starved due to something in kernel mode. Now it can't, and since said application is high priority, it will get the CPU when it wants it. This is not to say the preemption patch is no good if you don't run stuff at realtime -- I don't (who uses nice, anyhow? :), and I notice a difference. To test how well the latency patches are working you should be running things all at the same priority. The main issue people are having with skipping mp3s is not in the decoding of the mp3 or in the retrieving of the file, it's in the playing in the soundcard. That's being affected by dbench flooding the system with irq requests. I'm inclined to believe it's irq requests because the _only_ time i have problems with mp3s (and i dont change priority levels) is when A. i do a cdparanoia -Z -B 1-or dbench 32. I bet if someone did these tests on scsi hardware with the latency patch, they'd find much better results than us users of ide devices. The skips are really big to be irq requests, although perhaps you are right in that the handling of the irq (we disable preemption during irq_off, of course, but also during bottom half execution) is the problem. However, I am more inclined to believe it is something else. All these long held locks can indeed be the problem. I am on an all UW2 SCSI system, and I have no major blips playing during a `dbench 16' (never ran 32). However, many other users (Dieter, I believe) are on a SCSI system too. Dieter, could you post your .config file? It might have a clue or two. Here it comes. Good night ;-) -Dieter BTW I have very good results (not the hiccup) for 2.4.10-pre14 + ReiserFS journal.c-2-patch from Chris config.bz2 Description: BZip2 compressed data
Re: ASUS A7V/Thunderbird 1GHz lockup problems observation w/fix for me
>Ever since building this system there have been spontaneous and > unpredictable lockups, usually at least once per day. Sometimes several per > day. The lockup is sometimes preceded by X starting to display things > strangely (on a Voodoo 3 w/XF 4.X). Then I have a few minutes to reboot > before it hangs (can't log in using ssh from another system.) >With the Northbridge discussion, I couldn't pinpoint anything to fix it, > so I started experimenting. >Things got better by upgrading the BIOS; but still many hangs. >I've discovered that changing the CPU voltage from the default to 1.75V > results in a stable system. Higher than that doesn't work. Lower still gets > lockups. >It doesn't look like everyone has this problem with similar setups. But > if there are others, I wanted to share this discovery. How good is your power supply? Only to be sure. You know about AMD's recommendations for a proper power supply if you are building an AMD Athlon/Duron system. Things going better with Athlon (MP) 4 and mobile Duron. The dual Athlon MP systems are another story... ...but smooth performer (I love it). MSI has a very good summary on there German website. I've piped it through Babel and sounds a bit funny, but anyway:-) [-] Ref NR: 09-0001 05.04.2001 Question/symptom: The operating system cannot be installed with my new MSI Main board. A cause: High requirements of electric current of new PCUs, diagram cards, large memory modules and some PCI cards (e.g. TV cards) provide for it that the usual 250 Watts of power packs the necessary performance any longer do not apply. Response/solution: MSI recommends to use a sufficiently dimmensioniertes power pack with following minimum values. +3.3 V - 20 ampere +5.0 V - 30 ampere Power packs with these values have usually a total output of ca.350 Watt. Please you consider however it by this also power packs give those the specification given above do not fulfill (server power packs) and therefore are unsuitable. Ref NR: 09-0003 11.04.2001 Question/symptom: Why does my Athlon Main board have so high requirements of electric current? Response/solution: Measurements or specification in the AMD data sheets resulted in, measured the following current loads on the particularly critical 3.3V-Leitung during a time demo 1 (Crusher) of Quake 3 on a MS-6167 or a MS-6195 K7T pro: Component: Maximum stream on 3.3V AMD Athlon (all clock frequencies) 9,6 A Main board + 3 DIMM of modules 2,0 A NVIDIA Geforce 256 8,6 A Total: 20,2 A [-] I am, like Alan Cox (:-) on the Athlon track since August '99 and my local dealer where I do Linux consulting sells over 95% AMD CPUs since then... Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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: ASUS A7V/Thunderbird 1GHz lockup problems observation w/fix for me
Ever since building this system there have been spontaneous and unpredictable lockups, usually at least once per day. Sometimes several per day. The lockup is sometimes preceded by X starting to display things strangely (on a Voodoo 3 w/XF 4.X). Then I have a few minutes to reboot before it hangs (can't log in using ssh from another system.) With the Northbridge discussion, I couldn't pinpoint anything to fix it, so I started experimenting. Things got better by upgrading the BIOS; but still many hangs. I've discovered that changing the CPU voltage from the default to 1.75V results in a stable system. Higher than that doesn't work. Lower still gets lockups. It doesn't look like everyone has this problem with similar setups. But if there are others, I wanted to share this discovery. How good is your power supply? Only to be sure. You know about AMD's recommendations for a proper power supply if you are building an AMD Athlon/Duron system. Things going better with Athlon (MP) 4 and mobile Duron. The dual Athlon MP systems are another story... ...but smooth performer (I love it). MSI has a very good summary on there German website. I've piped it through Babel and sounds a bit funny, but anyway:-) [-] Ref NR: 09-0001 05.04.2001 Question/symptom: The operating system cannot be installed with my new MSI Main board. A cause: High requirements of electric current of new PCUs, diagram cards, large memory modules and some PCI cards (e.g. TV cards) provide for it that the usual 250 Watts of power packs the necessary performance any longer do not apply. Response/solution: MSI recommends to use a sufficiently dimmensioniertes power pack with following minimum values. +3.3 V - 20 ampere +5.0 V - 30 ampere Power packs with these values have usually a total output of ca.350 Watt. Please you consider however it by this also power packs give those the specification given above do not fulfill (server power packs) and therefore are unsuitable. Ref NR: 09-0003 11.04.2001 Question/symptom: Why does my Athlon Main board have so high requirements of electric current? Response/solution: Measurements or specification in the AMD data sheets resulted in, measured the following current loads on the particularly critical 3.3V-Leitung during a time demo 1 (Crusher) of Quake 3 on a MS-6167 or a MS-6195 K7T pro: Component: Maximum stream on 3.3V AMD Athlon (all clock frequencies) 9,6 A Main board + 3 DIMM of modules 2,0 A NVIDIA Geforce 256 8,6 A Total: 20,2 A [-] I am, like Alan Cox (:-) on the Athlon track since August '99 and my local dealer where I do Linux consulting sells over 95% AMD CPUs since then... Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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 2.4.5-ac21
Am Freitag, 29. Juni 2001 03:59 schrieb Dieter Nützel: > Hello Alan, > > you've missed the CONFIG_DRM_AGP thing. > Some other config objects (Input -> joysticks , SMB file system) are > broken, too. Keith Owens patch fixed it of course. http://marc.theaimsgroup.com/?l=linux-kernel=99378430115592=2 Thanks Keith! -Dieter - 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 2.4.5-ac21
Hello Alan,
you've missed the CONFIG_DRM_AGP thing.
Some other config objects (Input -> joysticks , SMB file system) are
broken, too.
Regards,
Dieter
can't read "CONFIG_DRM_AGP": no such variable
while executing
"list $CONFIG_DRM_AGP"
(procedure "writeconfig" line 2352)
invoked from within
"writeconfig .config include/linux/autoconf.h"
invoked from within
".f0.right.save invoke"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke]"
(procedure "tkButtonUp" line 7)
invoked from within
"tkButtonUp .f0.right.save
"
(command bound to event)
--
Dieter Nützel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany
email: [EMAIL PROTECTED]
@home: [EMAIL PROTECTED]
-
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 2.4.5-ac21
Am Freitag, 29. Juni 2001 03:59 schrieb Dieter Nützel: Hello Alan, you've missed the CONFIG_DRM_AGP thing. Some other config objects (Input - joysticks , SMB file system) are broken, too. Keith Owens patch fixed it of course. http://marc.theaimsgroup.com/?l=linux-kernelm=99378430115592w=2 Thanks Keith! -Dieter - 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-2.4.5-ac16/17/18: floppy driver problem with lilo boot disks?
Hello, I mount my bootdisk (minix filesystem) with "mount /dev/fd0 /mnt" and copy my new compiled kernel to it. After that I do a "lilo -v -C /mnt/lilo.conf". All following commands which are floppy related (filesystem) fall into the D state. Load goes up by 100 for every D state process. ls /mnt umount /mnt sync SunWave1#cat /proc/version Linux version 2.4.5-ac16 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Wed Jun 20 18:01:34 CEST 2001 SunWave1#ps aux root 1039 0.0 0.0 1404 64 pts/1D16:24 0:00 umount /mnt nuetzel 1108 0.1 0.1 1412 500 pts/5D16:28 0:00 sync Even "reboot" do nothing. I have to push the reset button. Luckily I have ReiserFS running and only some seconds to wait during bootup for replay the transaction logs. But mount/umount other disk partitions works as expected. Thanks, Dieter - 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-2.4.5-ac16/17/18: floppy driver problem with lilo boot disks?
Hello, I mount my bootdisk (minix filesystem) with mount /dev/fd0 /mnt and copy my new compiled kernel to it. After that I do a lilo -v -C /mnt/lilo.conf. All following commands which are floppy related (filesystem) fall into the D state. Load goes up by 100 for every D state process. ls /mnt umount /mnt sync SunWave1#cat /proc/version Linux version 2.4.5-ac16 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Wed Jun 20 18:01:34 CEST 2001 SunWave1#ps aux root 1039 0.0 0.0 1404 64 pts/1D16:24 0:00 umount /mnt nuetzel 1108 0.1 0.1 1412 500 pts/5D16:28 0:00 sync Even reboot do nothing. I have to push the reset button. Luckily I have ReiserFS running and only some seconds to wait during bootup for replay the transaction logs. But mount/umount other disk partitions works as expected. Thanks, Dieter - 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: Some experience of linux on a Laptop
Alan wrote: > > > 4: make bzImage && make modules && make modules install && cp > > arch/i386/boot/bzImage /boot/'uname -r' something inside make menuconfig > > So really you want an outside GUI tool that lets you reconfigure build and > install kernels. Yeah I'd agree with that. Someone just needs to write the > killer gnome/kde config tool. I've got C code for parsing/loading config.in > files and deducing the dependancy constraints if anyone ever wants to try > and write such a tool 8) KDE-2.2 will do this. I have KDE-2.2alpha2 running here (beta1 is around the corner) and it has it included. I looked at it but didn't tested it, yet. KDE Control Center --> System --> Linux Kernel Configurator > > 8: A way to change kernel without rebooting. I have no diskdrive or > > cddrive in my laptop so I often do drastic things when I install a new > > distribution. > > Thats actually an incredibly hard problem to solve. The only people who do > this level of stuff are some of the telephony folks, and the expensive > tandem non-stop boxes. SUN Enterprise IBM S/390 (zSeries) etc... -Dieter - 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: Some experience of linux on a Laptop
Alan wrote: 4: make bzImage make modules make modules install cp arch/i386/boot/bzImage /boot/'uname -r' something inside make menuconfig So really you want an outside GUI tool that lets you reconfigure build and install kernels. Yeah I'd agree with that. Someone just needs to write the killer gnome/kde config tool. I've got C code for parsing/loading config.in files and deducing the dependancy constraints if anyone ever wants to try and write such a tool 8) KDE-2.2 will do this. I have KDE-2.2alpha2 running here (beta1 is around the corner) and it has it included. I looked at it but didn't tested it, yet. KDE Control Center -- System -- Linux Kernel Configurator 8: A way to change kernel without rebooting. I have no diskdrive or cddrive in my laptop so I often do drastic things when I install a new distribution. Thats actually an incredibly hard problem to solve. The only people who do this level of stuff are some of the telephony folks, and the expensive tandem non-stop boxes. SUN Enterprise IBM S/390 (zSeries) etc... -Dieter - 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-2.4.5-ac17 --- Where is the truncate_inode_pages speedup patch?
Hello Alan,
I use it all the time and it is not pre6 stuff related...:-)
Thanks,
Dieter
--- linux/mm/filemap.cMon May 28 13:31:49 2001
+++ linux/mm/filemap.c Mon Jun 11 23:31:08 2001
@@ -230,17 +230,17 @@
unsigned long offset;
page = list_entry(curr, struct page, list);
- curr = curr->next;
offset = page->index;
/* Is one of the pages to truncate? */
if ((offset >= start) || (*partial && (offset + 1) == start))
{
+ list_del(head);
+ list_add(head, curr);
if (TryLockPage(page)) {
page_cache_get(page);
spin_unlock(_lock);
wait_on_page(page);
- page_cache_release(page);
- return 1;
+ goto out_restart;
}
page_cache_get(page);
spin_unlock(_lock);
@@ -252,11 +252,15 @@
truncate_complete_page(page);
UnlockPage(page);
- page_cache_release(page);
- return 1;
+ goto out_restart;
}
+ curr = curr->next;
}
return 0;
+out_restart:
+ page_cache_release(page);
+ spin_lock(_lock);
+ return 1;
}
@@ -273,15 +277,19 @@
{
unsigned long start = (lstart + PAGE_CACHE_SIZE - 1) >>
PAGE_CACHE_SHIFT;
unsigned partial = lstart & (PAGE_CACHE_SIZE - 1);
+ int complete;
-repeat:
spin_lock(_lock);
- if (truncate_list_pages(>clean_pages, start, ))
- goto repeat;
- if (truncate_list_pages(>dirty_pages, start, ))
- goto repeat;
- if (truncate_list_pages(>locked_pages, start, ))
- goto repeat;
+ do {
+ complete = 1;
+ while (truncate_list_pages(>clean_pages, start,
))
+ complete = 0;
+ while (truncate_list_pages(>dirty_pages, start,
))
+ complete = 0;
+ while (truncate_list_pages(>locked_pages, start,
))
+ complete = 0;
+ } while (!complete);
+ /* Traversed all three lists without dropping the lock */
spin_unlock(_lock);
}
-
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-2.4.5-ac17 --- Where is the truncate_inode_pages speedup patch?
Hello Alan,
I use it all the time and it is not pre6 stuff related...:-)
Thanks,
Dieter
--- linux/mm/filemap.cMon May 28 13:31:49 2001
+++ linux/mm/filemap.c Mon Jun 11 23:31:08 2001
@@ -230,17 +230,17 @@
unsigned long offset;
page = list_entry(curr, struct page, list);
- curr = curr-next;
offset = page-index;
/* Is one of the pages to truncate? */
if ((offset = start) || (*partial (offset + 1) == start))
{
+ list_del(head);
+ list_add(head, curr);
if (TryLockPage(page)) {
page_cache_get(page);
spin_unlock(pagecache_lock);
wait_on_page(page);
- page_cache_release(page);
- return 1;
+ goto out_restart;
}
page_cache_get(page);
spin_unlock(pagecache_lock);
@@ -252,11 +252,15 @@
truncate_complete_page(page);
UnlockPage(page);
- page_cache_release(page);
- return 1;
+ goto out_restart;
}
+ curr = curr-next;
}
return 0;
+out_restart:
+ page_cache_release(page);
+ spin_lock(pagecache_lock);
+ return 1;
}
@@ -273,15 +277,19 @@
{
unsigned long start = (lstart + PAGE_CACHE_SIZE - 1)
PAGE_CACHE_SHIFT;
unsigned partial = lstart (PAGE_CACHE_SIZE - 1);
+ int complete;
-repeat:
spin_lock(pagecache_lock);
- if (truncate_list_pages(mapping-clean_pages, start, partial))
- goto repeat;
- if (truncate_list_pages(mapping-dirty_pages, start, partial))
- goto repeat;
- if (truncate_list_pages(mapping-locked_pages, start, partial))
- goto repeat;
+ do {
+ complete = 1;
+ while (truncate_list_pages(mapping-clean_pages, start,
partial))
+ complete = 0;
+ while (truncate_list_pages(mapping-dirty_pages, start,
partial))
+ complete = 0;
+ while (truncate_list_pages(mapping-locked_pages, start,
partial))
+ complete = 0;
+ } while (!complete);
+ /* Traversed all three lists without dropping the lock */
spin_unlock(pagecache_lock);
}
-
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 2.4.5-ac14
Am Freitag, 15. Juni 2001 04:30 schrieb John Cavan: > Dieter Nützel wrote: > > Hello Alan, > > > > I see 4.29 GB under shm with your latest try. > > something wrong? > > total:used:free: shared: buffers: cached: > Mem: 1053483008 431419392 622063616 122880 24387584 260923392 > Swap: 3947642880 394764288 > MemTotal: 1028792 kB > MemFree:607484 kB > MemShared: 120 kB > Buffers: 23816 kB > Cached: 254808 kB > Active: 225536 kB > Inact_dirty: 53208 kB > Inact_clean: 0 kB > Inact_target: 44 kB > HighTotal: 131056 kB > HighFree: 1048 kB > LowTotal: 897736 kB > LowFree:606436 kB > SwapTotal: 385512 kB > SwapFree: 385512 kB > > I don't seem to have the problem... You are using HIGHMEM?! -Dieter - 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 2.4.5-ac14
Hello Alan, I see 4.29 GB under shm with your latest try. something wrong? Regards, Dieter SunWave1>cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 327802880 322592768 5210112 4294184960 8417280 253640704 Swap: 1052794880 95768576 957026304 MemTotal: 320120 kB MemFree: 5088 kB MemShared:4294966532 kB Buffers: 8220 kB Cached: 247696 kB Active: 228008 kB Inact_dirty: 24552 kB Inact_clean: 2592 kB Inact_target: 468 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 320120 kB LowFree: 5088 kB SwapTotal: 1028120 kB SwapFree: 934596 kB - 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: threading question (results after thread pooling)
> Hello,
>
> I have implemented thread pooling (with an environment variable
> where I can give the number of threads to be created). Results:
>
> 1. Linux, no change in the times (not under 2.2.x or 2.4)
[snip]
> I am now pretty much inclined to believe that it is either a) hardware
> issue (someone mentioned that SPARCs and MIPSes handle things differently)
> or b) Linux for some reason just cant give me what IRIX/Solaris can in
> this particular case
[snip]
Hello Ognen,
can you get your hands on an dual AMD Athlon MP 1/1.2 GHz system?
The only mobo currently on the marked is the AMD 760MP based Tyan Thunder K7.
It has (all) the good stuff (Point-to-Point bus, crossbar) which former only
the (big) Alphas/SUN/SGI etc. had.
http://www.amd.com/products/cpg/server/athlon/index.html
http://www.tyan.com/products/html/thunderk7.html
Regards,
Dieter
--
Dieter Nützel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany
email: [EMAIL PROTECTED]
@home: [EMAIL PROTECTED]
-
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: threading question (results after thread pooling)
Hello, I have implemented thread pooling (with an environment variable where I can give the number of threads to be created). Results: 1. Linux, no change in the times (not under 2.2.x or 2.4) [snip] I am now pretty much inclined to believe that it is either a) hardware issue (someone mentioned that SPARCs and MIPSes handle things differently) or b) Linux for some reason just cant give me what IRIX/Solaris can in this particular case [snip] Hello Ognen, can you get your hands on an dual AMD Athlon MP 1/1.2 GHz system? The only mobo currently on the marked is the AMD 760MP based Tyan Thunder K7. It has (all) the good stuff (Point-to-Point bus, crossbar) which former only the (big) Alphas/SUN/SGI etc. had. http://www.amd.com/products/cpg/server/athlon/index.html http://www.tyan.com/products/html/thunderk7.html Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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 2.4.5-ac14
Hello Alan, I see 4.29 GB under shm with your latest try. something wrong? Regards, Dieter SunWave1cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 327802880 322592768 5210112 4294184960 8417280 253640704 Swap: 1052794880 95768576 957026304 MemTotal: 320120 kB MemFree: 5088 kB MemShared:4294966532 kB Buffers: 8220 kB Cached: 247696 kB Active: 228008 kB Inact_dirty: 24552 kB Inact_clean: 2592 kB Inact_target: 468 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 320120 kB LowFree: 5088 kB SwapTotal: 1028120 kB SwapFree: 934596 kB - 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: Changing CPU Speed while running Linux
Arjan van de Ven wrote:
>
> Sven Geggus wrote:
> >
> > Hi there,
> >
> > on my Elan410 based System it is very easy to change the CPU clock
> > speed by means od two outb commands.
> >
> > I was wondering, if it does some harm to the Kernel if the CPU is
> > reprogrammed using a different CPU clock speed, while the system is up and
> > running.
>
> I have a module for the K6 PowerNow which allows you to do
>
> echo 450 > /proc/sys/cpu/0/frequency
>
> and does the right thing wrt udelay / bogomips etc..
> I can dig it out if you want.. sounds like this should be a more generic
> thing.
Yes, please.
After (all) Athlon 4/MT (Palomino) and Duron mobile feature PowerNow! it
should be usefull for more and more people.
Regards,
Dieter
BTW I think there are only a "few" K6-2+/K6-III+ out ;-)
But PowerNow! is nice stuff. I had an eye on an 1 GHz Palomino
at CeBIT '2001.
--
Dieter Nützel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany
email: [EMAIL PROTECTED]
@home: [EMAIL PROTECTED]
-
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: Changing CPU Speed while running Linux
Arjan van de Ven wrote: Sven Geggus wrote: Hi there, on my Elan410 based System it is very easy to change the CPU clock speed by means od two outb commands. I was wondering, if it does some harm to the Kernel if the CPU is reprogrammed using a different CPU clock speed, while the system is up and running. I have a module for the K6 PowerNow which allows you to do echo 450 /proc/sys/cpu/0/frequency and does the right thing wrt udelay / bogomips etc.. I can dig it out if you want.. sounds like this should be a more generic thing. Yes, please. After (all) Athlon 4/MT (Palomino) and Duron mobile feature PowerNow! it should be usefull for more and more people. Regards, Dieter BTW I think there are only a few K6-2+/K6-III+ out ;-) But PowerNow! is nice stuff. I had an eye on an 1 GHz Palomino at CeBIT '2001. -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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] truncate_inode_pages
Am Dienstag, 12. Juni 2001 14:32 schrieb Daniel Phillips: > On Tuesday 12 June 2001 02:00, you wrote: > > Now with -ac13 and the third try. > > Is it final? > > There have been no further problems reported, but it's Andrew Morton's > patch, his decision. > > -- > Daniel Hello Andrew, have you forwarded it to Alan for apply? Thanks, Dieter - 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] truncate_inode_pages
Am Dienstag, 12. Juni 2001 14:32 schrieb Daniel Phillips: On Tuesday 12 June 2001 02:00, you wrote: Now with -ac13 and the third try. Is it final? There have been no further problems reported, but it's Andrew Morton's patch, his decision. -- Daniel Hello Andrew, have you forwarded it to Alan for apply? Thanks, Dieter - 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/
2.4.5-ac12: 3c590.c: Warning about 'nopnp' parameter
Taken from boot.msg: Setting up network device eth1 insmod: Warning: /lib/modules/2.4.5-ac12/kernel/drivers/net/3c509.o symbol for parameter nopnp not found done I've tried with and without ISA PNP support. Any hints? Thanks, Dieter - 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] truncate_inode_pages
> Daniel Phillips wrote: > > > > This is easy, just set the list head to the page about to be truncated. > > Works for me. > > --- linux-2.4.5/mm/filemap.cMon May 28 13:31:49 2001 > +++ linux-akpm/mm/filemap.c Sun Jun 10 11:29:19 2001 > @@ -235,12 +235,13 @@ [snip] Works for me 12 times faster on my Athlon 550 and ReiserFS. System: Athlon 550 (old one, 0.25 µm) MSI MS-6167 Rev 1.0B (Irongate C4) 320 MB SDRAM PC100-2-2-2 AHA-2940UW IBM DDYS-T18350N 18 GB (UW/U160) Kernel 2.4.5-ac12 Glibc-2.2 (SuSE 7.1) SunWave1>cat /proc/version Linux version 2.4.5-ac12 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Sat Jun 9 17:41:07 CEST 2001 SunWave1>time ./ftruncate 0.430u 54.790s 1:00.09 91.8%0+0k 0+0io 32887pf+0w With the mm/filemap.c fix: SunWave1>cat /proc/version Linux version 2.4.5-ac12 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Sun Jun 10 22:49:07 CEST 2001 SunWave1>time ./ftruncate 0.220u 1.670s 0:05.13 36.8% 0+0k 0+0io 32852pf+0w Thanks, Dieter - 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: 2.4.5-ac13: Where is your change log gone? Can't find it on LKM.
Am Sonntag, 10. Juni 2001 22:02 schrieb Frank Davis: > Dieter, >I don't believe Alan has posted it yet...should be out soon. > Regards, > Frank Sorry Frank, I have it since 20.00 CEST (UT +0200). It is on ftp.de.kernel.org/pub/linux/kernel/people/alan/2.4 since 17:42 CEST. Regards, Dieter - 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/
2.4.5-ac13: Where is your change log gone? Can't find it on LKM.
Thanks, Dieter - 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/
2.4.5-ac13: Where is your change log gone? Can't find it on LKM.
Thanks, Dieter - 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: 2.4.5-ac13: Where is your change log gone? Can't find it on LKM.
Am Sonntag, 10. Juni 2001 22:02 schrieb Frank Davis: Dieter, I don't believe Alan has posted it yet...should be out soon. Regards, Frank Sorry Frank, I have it since 20.00 CEST (UT +0200). It is on ftp.de.kernel.org/pub/linux/kernel/people/alan/2.4 since 17:42 CEST. Regards, Dieter - 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] truncate_inode_pages
Daniel Phillips wrote: This is easy, just set the list head to the page about to be truncated. Works for me. --- linux-2.4.5/mm/filemap.cMon May 28 13:31:49 2001 +++ linux-akpm/mm/filemap.c Sun Jun 10 11:29:19 2001 @@ -235,12 +235,13 @@ [snip] Works for me 12 times faster on my Athlon 550 and ReiserFS. System: Athlon 550 (old one, 0.25 µm) MSI MS-6167 Rev 1.0B (Irongate C4) 320 MB SDRAM PC100-2-2-2 AHA-2940UW IBM DDYS-T18350N 18 GB (UW/U160) Kernel 2.4.5-ac12 Glibc-2.2 (SuSE 7.1) SunWave1cat /proc/version Linux version 2.4.5-ac12 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Sat Jun 9 17:41:07 CEST 2001 SunWave1time ./ftruncate 0.430u 54.790s 1:00.09 91.8%0+0k 0+0io 32887pf+0w With the mm/filemap.c fix: SunWave1cat /proc/version Linux version 2.4.5-ac12 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Sun Jun 10 22:49:07 CEST 2001 SunWave1time ./ftruncate 0.220u 1.670s 0:05.13 36.8% 0+0k 0+0io 32852pf+0w Thanks, Dieter - 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/
2.4.5-ac12: 3c590.c: Warning about 'nopnp' parameter
Taken from boot.msg: Setting up network device eth1 insmod: Warning: /lib/modules/2.4.5-ac12/kernel/drivers/net/3c509.o symbol for parameter nopnp not found done I've tried with and without ISA PNP support. Any hints? Thanks, Dieter - 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/
Dual AMD Palomino from Australia
Hello Alan, do you have an dual AMD 760MP based mobo, too? It should be more interesting to see some multi processing workloads. Here are the links: http://www.overclockers.com.au/techstuff/a_tyan_thunder/ http://www.overclockers.com.au/techstuff/a_tyan_thunder/page2.shtml http://www.overclockers.com.au/techstuff/a_tyan_thunder/boot.txt Thanks, Dieter - 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/
Dual AMD Palomino from Australia
Hello Alan, do you have an dual AMD 760MP based mobo, too? It should be more interesting to see some multi processing workloads. Here are the links: http://www.overclockers.com.au/techstuff/a_tyan_thunder/ http://www.overclockers.com.au/techstuff/a_tyan_thunder/page2.shtml http://www.overclockers.com.au/techstuff/a_tyan_thunder/boot.txt Thanks, Dieter - 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: missing sysrq
Am Freitag, 1. Juni 2001 16:51 schrieben Sie: > > Have you tried "echo 1 > /proc/sys/kernel/sysrq"? > > You need both, compiled in and activation. > > no, look at the code. the enable variable defaults to 1. Then there must be a bug? I get "0" with 2.4.5-ac2 and -ac5 without "echo 1". Fresh booted 2.4.5-ac2: SunWave1>cat /proc/version Linux version 2.4.5-ac2 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Mon May 28 05:42:09 CEST 2001 SunWave1>cat /proc/sys/kernel/sysrq 0 -Dieter - 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: missing sysrq
Am Freitag, 1. Juni 2001 16:51 schrieben Sie: Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. no, look at the code. the enable variable defaults to 1. Then there must be a bug? I get 0 with 2.4.5-ac2 and -ac5 without echo 1. Fresh booted 2.4.5-ac2: SunWave1cat /proc/version Linux version 2.4.5-ac2 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Mon May 28 05:42:09 CEST 2001 SunWave1cat /proc/sys/kernel/sysrq 0 -Dieter - 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: missing sysrq
> D. Stimits wrote: > > > Bernd Eckenfels wrote: > > > > > In article <[EMAIL PROTECTED]> you wrote: > > > However, if I go to /proc/sys/kernel/sysrq does not exist. > > > > It is a compile time option, so the person who compiled your kernel > > left it out. > > I compiled it, and the sysrq is definitely in the config. No doubt at > all. I also use make mrproper and config again before dep and actual > compile. Maybe it is just a quirk/oddball. > > D. Stimits, [EMAIL PROTECTED] Have you tried "echo 1 > /proc/sys/kernel/sysrq"? You need both, compiled in and activation. Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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: missing sysrq
D. Stimits wrote: Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] Have you tried echo 1 /proc/sys/kernel/sysrq? You need both, compiled in and activation. Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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: [RFC][PATCH] Re: Linux 2.4.4-ac10
> > Three back to back make -j 30 runs for three different kernels. > > Swap cache numbers are taken immediately after last completion. > > The performance increase is nice, though. Do you see similar > changes in different kinds of workloads ? I you have a patch against 2.4.4-ac11 I will do some tests with some (interactive) 3D apps. -Dieter - 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/
Has anybody a working pppoed for 2.4 (2.4.4-ac10/11)?
I have pppoed-0.48b1-6, ppp-2.4.0-5 (SuSE 7.1) but it didn't work (with kernel pppoe.o/pppox.o). So I have to use rp-pppoe-2.5-5 (which should be slower I've heard) for the German Telekom ADSL (product name TDSL). Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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/
Has anybody a working pppoed for 2.4 (2.4.4-ac10/11)?
I have pppoed-0.48b1-6, ppp-2.4.0-5 (SuSE 7.1) but it didn't work (with kernel pppoe.o/pppox.o). So I have to use rp-pppoe-2.5-5 (which should be slower I've heard) for the German Telekom ADSL (product name TDSL). Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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: [RFC][PATCH] Re: Linux 2.4.4-ac10
Three back to back make -j 30 runs for three different kernels. Swap cache numbers are taken immediately after last completion. The performance increase is nice, though. Do you see similar changes in different kinds of workloads ? I you have a patch against 2.4.4-ac11 I will do some tests with some (interactive) 3D apps. -Dieter - 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: REVISED: Experimentation with Athlon and fast_page_copy
Am Samstag, 5. Mai 2001 09:13 schrieben Sie: > > My (very) old Athlon 550 (model 1, stepping 2) show it on my MSI MS-6167 > > (AMD Irongate C4) with your 2.4.4-ac5, now :-( > > Manfred has a good explanation for that. Im hoping it also explains the > VIA problem too > > > I am open for any test fixes... > > Watch this space -> <- ;) > > Alan Sorry for my noise! My problem was NOT fast_page_copy related. It was Justin's aic7xxx 6.1.12 release. His latest 6.1.13 (2.4.4-ac6) fixed it for me. My MSI MS-6167 (AMD Irongate C4) is running very well with APIC (it haven't really have one) and ACPI (latest) enabled. Below are some MMX copy results. Thanks anyway. Dieter BTW Where can I grep the bench with MB/sec output? SunWave1>./athlon Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ clear_page() tests clear_page function 'warm up run'took 17396 cycles per page clear_page function '2.4 non MMX'took 9582 cycles per page clear_page function '2.4 MMX fallback' took 9031 cycles per page clear_page function '2.4 MMX version'took 7905 cycles per page clear_page function 'faster_clear_page' took 8237 cycles per page clear_page function 'even_faster_clear' took 8151 cycles per page copy_page() tests copy_page function 'warm up run' took 12565 cycles per page copy_page function '2.4 non MMX' took 17273 cycles per page copy_page function '2.4 MMX fallback'took 17481 cycles per page copy_page function '2.4 MMX version' took 12507 cycles per page copy_page function 'faster_copy' took 13641 cycles per page copy_page function 'even_faster' took 12707 cycles per page - 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: REVISED: Experimentation with Athlon and fast_page_copy
Am Samstag, 5. Mai 2001 09:13 schrieben Sie: My (very) old Athlon 550 (model 1, stepping 2) show it on my MSI MS-6167 (AMD Irongate C4) with your 2.4.4-ac5, now :-( Manfred has a good explanation for that. Im hoping it also explains the VIA problem too I am open for any test fixes... Watch this space - - ;) Alan Sorry for my noise! My problem was NOT fast_page_copy related. It was Justin's aic7xxx 6.1.12 release. His latest 6.1.13 (2.4.4-ac6) fixed it for me. My MSI MS-6167 (AMD Irongate C4) is running very well with APIC (it haven't really have one) and ACPI (latest) enabled. Below are some MMX copy results. Thanks anyway. Dieter BTW Where can I grep the bench with MB/sec output? SunWave1./athlon Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $ clear_page() tests clear_page function 'warm up run'took 17396 cycles per page clear_page function '2.4 non MMX'took 9582 cycles per page clear_page function '2.4 MMX fallback' took 9031 cycles per page clear_page function '2.4 MMX version'took 7905 cycles per page clear_page function 'faster_clear_page' took 8237 cycles per page clear_page function 'even_faster_clear' took 8151 cycles per page copy_page() tests copy_page function 'warm up run' took 12565 cycles per page copy_page function '2.4 non MMX' took 17273 cycles per page copy_page function '2.4 MMX fallback'took 17481 cycles per page copy_page function '2.4 MMX version' took 12507 cycles per page copy_page function 'faster_copy' took 13641 cycles per page copy_page function 'even_faster' took 12707 cycles per page - 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: REVISED: Experimentation with Athlon and fast_page_copy
> What still stands out is that exactly _zero_ people have reported the same > problem with non VIA chipset Athlons. Sorry Alan, but... My (very) old Athlon 550 (model 1, stepping 2) show it on my MSI MS-6167 (AMD Irongate C4) with your 2.4.4-ac5, now :-( Even with or without apm/acpi enabled. It freezes during "Freeing unused kernel memory: 172k freed". Never saw this before. I am open for any test fixes... -Dieter SuSE 7.1 (glibc-2.2, gcc-2.95.2) Linux version 2.4.4 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Sun Apr 29 02:30:34 CEST 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 13ff (usable) BIOS-e820: 13ff - 13ff3000 (ACPI NVS) BIOS-e820: 13ff3000 - 1400 (ACPI data) BIOS-e820: - 0001 (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009f800 for 4096 bytes. On node 0 totalpages: 81904 zone(0): 4096 pages. zone(1): 77808 pages. zone(2): 0 pages. mapped APIC to e000 (01555000) SunWave1>cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 1 model name : AMD-K7(tm) Processor stepping: 2 cpu MHz : 548.950 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx syscall mmxext 3dnowext 3dnow bogomips: 1094.45 -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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: REVISED: Experimentation with Athlon and fast_page_copy
What still stands out is that exactly _zero_ people have reported the same problem with non VIA chipset Athlons. Sorry Alan, but... My (very) old Athlon 550 (model 1, stepping 2) show it on my MSI MS-6167 (AMD Irongate C4) with your 2.4.4-ac5, now :-( Even with or without apm/acpi enabled. It freezes during Freeing unused kernel memory: 172k freed. Never saw this before. I am open for any test fixes... -Dieter SuSE 7.1 (glibc-2.2, gcc-2.95.2) Linux version 2.4.4 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Sun Apr 29 02:30:34 CEST 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 13ff (usable) BIOS-e820: 13ff - 13ff3000 (ACPI NVS) BIOS-e820: 13ff3000 - 1400 (ACPI data) BIOS-e820: - 0001 (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009f800 for 4096 bytes. On node 0 totalpages: 81904 zone(0): 4096 pages. zone(1): 77808 pages. zone(2): 0 pages. mapped APIC to e000 (01555000) SunWave1cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 1 model name : AMD-K7(tm) Processor stepping: 2 cpu MHz : 548.950 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx syscall mmxext 3dnowext 3dnow bogomips: 1094.45 -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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 2.4.3-ac12
> My belief however is that several million people have gcc 2.96-69+, about 50
> are likely to have random cvs snapshots and none of them are going to build
> kernels with them anyway, as they wont work __builtin_expect or otherwise.
>
> Alan
I will not add fuel to the fire, but isn't 2.4.XX the "stable" version?
And I think most people (here in Europe :-) are running 2.95.2 at the moment.
But, yes the previously patches fixed it.
Thanks,
Dieter
--
Dieter Nützel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany
email: [EMAIL PROTECTED]
@home: [EMAIL PROTECTED]
-
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 2.4.3-ac12
My belief however is that several million people have gcc 2.96-69+, about 50 are likely to have random cvs snapshots and none of them are going to build kernels with them anyway, as they wont work __builtin_expect or otherwise. Alan I will not add fuel to the fire, but isn't 2.4.XX the "stable" version? And I think most people (here in Europe :-) are running 2.95.2 at the moment. But, yes the previously patches fixed it. Thanks, Dieter -- Dieter Ntzel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Klln-Strae 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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] ppp_generic, kernel 2.4.
Hello Tim, it seems to me to that there is one little commentary close (*/) to much. + * A ConfReq indicates what the sender would like to receive */ + */ should be + * A ConfReq indicates what the sender would like to receive + */ Have a nice weekend. -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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] ppp_generic, kernel 2.4.
Hello Tim, it seems to me to that there is one little commentary close (*/) to much. + * A ConfReq indicates what the sender would like to receive */ + */ should be + * A ConfReq indicates what the sender would like to receive + */ Have a nice weekend. -Dieter -- Dieter Ntzel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Klln-Strae 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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 2.4.2ac25
I got the following compilation error with aic7xxx (sorry, $LANGUAGE=german :-) make[5]: Entering directory `/usr/src/linux-2.4.2-ac25/drivers/scsi/aic7xxx/aicasm' if [ -e "/usr/include/db3/db_185.h" ]; then \ echo "#include " > aicdb.h; \ elif [ -e "/usr/include/db_185.h" ]; then \ echo "#include " > aicdb.h; \ elif [ -e "/usr/include/db/db_185.h" ]; then\ echo "#include " > aicdb.h;\ elif [ -e "/usr/include/db2/db_185.h" ]; then \ echo "#include " > aicdb.h; \ elif [ -e "/usr/include/db1/db_185.h" ]; then \ echo "#include " > aicdb.h; \ else\ echo "*** Install db development libraries";\ fi gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm/aicasm_gram.y:45: ../queue.h: Datei oder Verzeichnis nicht gefunden aicasm/aicasm_gram.y:50: aicasm.h: Datei oder Verzeichnis nicht gefunden aicasm/aicasm_gram.y:51: aicasm_symbol.h: Datei oder Verzeichnis nicht gefunden aicasm/aicasm_gram.y:52: aicasm_insformat.h: Datei oder Verzeichnis nicht gefunden aicasm/aicasm_scan.l:44: ../queue.h: Datei oder Verzeichnis nicht gefunden aicasm/aicasm_scan.l:49: aicasm.h: Datei oder Verzeichnis nicht gefunden aicasm/aicasm_scan.l:50: aicasm_symbol.h: Datei oder Verzeichnis nicht gefunden aicasm/aicasm_scan.l:51: y.tab.h: Datei oder Verzeichnis nicht gefunden make[5]: *** [aicasm] Error 1 make[5]: Leaving directory `/usr/src/linux-2.4.2-ac25/drivers/scsi/aic7xxx/aicasm' make[4]: *** [aicasm/aicasm] Error 2 make[4]: Leaving directory `/usr/src/linux-2.4.2-ac25/drivers/scsi/aic7xxx' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.2-ac25/drivers/scsi/aic7xxx' make[2]: *** [_subdir_aic7xxx] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.2-ac25/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.2-ac25/drivers' make: *** [_dir_drivers] Error 2 -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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 2.4.2 fails to merge mmap areas, 700% slowdown.
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> Cool. Somebody actually found a real case.
>
> I'll fix the mmap case asap. Its' not hard, I just waited to see if it
> ever actually triggers. Something like g++ certainly counts as major.
I do daily builds of the VTK CVS tree (The Visualization Toolkit,
www.kitware.com/vtk.html, a huge 3D app).
~33 MB C++ source
It took ~1 hour on my K7 550, 256 MB, IBM DTL-307030, glibc-2.2 and
gcc-2.95.2 ( 19991024 (release)) under most of the 2.4-test kernels (all with
ReiserFS) for a whole rebuild.
Now it take nearly 1 and a half hour with 2.4.2-ac20.
BTW My mouse (PS2) is very sluggished during C++ compilations, now.
I am open for all of your patches. Or should I better say most :-)))
Cheers,
Dieter
--
Dieter Nützel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany
email: [EMAIL PROTECTED]
@home: [EMAIL PROTECTED]
-
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 2.4.2 fails to merge mmap areas, 700% slowdown.
Linus Torvalds [EMAIL PROTECTED] writes: Cool. Somebody actually found a real case. I'll fix the mmap case asap. Its' not hard, I just waited to see if it ever actually triggers. Something like g++ certainly counts as major. I do daily builds of the VTK CVS tree (The Visualization Toolkit, www.kitware.com/vtk.html, a huge 3D app). ~33 MB C++ source It took ~1 hour on my K7 550, 256 MB, IBM DTL-307030, glibc-2.2 and gcc-2.95.2 ( 19991024 (release)) under most of the 2.4-test kernels (all with ReiserFS) for a whole rebuild. Now it take nearly 1 and a half hour with 2.4.2-ac20. BTW My mouse (PS2) is very sluggished during C++ compilations, now. I am open for all of your patches. Or should I better say most :-))) Cheers, Dieter -- Dieter Ntzel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Klln-Strae 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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: Announce: ksymoops 2.4.1 is available
Sorry, Keith, but I can't find it all over the world? I've looked at au, uk, us, fi, de, ... Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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: Announce: ksymoops 2.4.1 is available
Sorry, Keith, but I can't find it all over the world? I've looked at au, uk, us, fi, de, ... Thanks, Dieter -- Dieter Ntzel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Klln-Strae 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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/
pmap.c : Can you please try another name for it?
Hello Rik, there is a nice little toy called "pmap.c" around for several years, now. Should we consider? /* * pmap.c: implementation of something like Solaris' /usr/proc/bin/pmap * for linux * * Author: Andy Isaacson <[EMAIL PROTECTED]> * Fri Jun 18 1999 * * Updated Mon Oct 25 1999 * - calculate total size of shared mappings * - change output format to read "writable/private" rather than "writable" * * Justification: the formatting available in /proc//maps is less * than optimal. It's hard to figure out the size of a mapping from * that information (unless you can do 8-digit hex arithmetic in your * head) and it's just generally not friendly. Hence this utility. * * I hereby place this work in the public domain. * * Compile with something along the lines of * gcc -O pmap.c -o pmap */ Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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/
pmap.c : Can you please try another name for it?
Hello Rik, there is a nice little toy called "pmap.c" around for several years, now. Should we consider? /* * pmap.c: implementation of something like Solaris' /usr/proc/bin/pmap * for linux * * Author: Andy Isaacson [EMAIL PROTECTED] * Fri Jun 18 1999 * * Updated Mon Oct 25 1999 * - calculate total size of shared mappings * - change output format to read "writable/private" rather than "writable" * * Justification: the formatting available in /proc/pid/maps is less * than optimal. It's hard to figure out the size of a mapping from * that information (unless you can do 8-digit hex arithmetic in your * head) and it's just generally not friendly. Hence this utility. * * I hereby place this work in the public domain. * * Compile with something along the lines of * gcc -O pmap.c -o pmap */ Regards, Dieter -- Dieter Ntzel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Klln-Strae 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - 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/
2.4.2-pre1: kernel oops during unmount
2.4.2-pre1 + ReiserFS 3.6.25 (included) + loop-4 ksymoops 2.3.7 on i686 2.4.2-pre1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2-pre1/ (default) -m /boot/System.map (specified) Unable to handle kernel NULL pointer dereference at virtual address c0143023 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00013206 eax: c14d3e00 ebx: c81051c0 ecx: cfa3f000 edx: cf7f36c0 esi: edi: ebp: ce469f3c esp: ce469f04 ds: 0018 es: 0018 ss: 0018 Process umount (pid: 9117, stackpage=ce469000) Stack: c14d3e00 ce469f3c ce469f3c c025d5b8 c01430d5 c025bf1c c14d3e00 ce469f3c c14d3e00 cf9b32c0 c025d580 c025d5b8 ce469f3c ce469f3c c01354d3 c14d3e00 c14c0440 c14d3e00 b53c c0134839 c01358d1 Call Trace: [] [] [] [] [] [] [] [] Code: 8b 3f 3b 74 24 1c 74 65 8d 5e f8 8b 44 24 20 39 83 8c 00 00 >>EIP; c0143023<= Trace; c01430d5 Trace; c01354d3 Trace; c0134839 Trace; c01358d1 Trace; c01359aa Trace; c0122fcb Trace; c01359eb Trace; c0108fe7 Code; c0143023 <_EIP>: Code; c0143023<= 0: 8b 3f mov(%edi),%edi <= Code; c0143025 2: 3b 74 24 1c cmp0x1c(%esp,1),%esi Code; c0143029 6: 74 65 je 6d <_EIP+0x6d> c0143090 Code; c014302b 8: 8d 5e f8 lea0xfff8(%esi),%ebx Code; c014302e b: 8b 44 24 20 mov0x20(%esp,1),%eax Code; c0143032 f: 39 83 8c 00 00 00 cmp%eax,0x8c(%ebx) -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11 / ll_rw_b watermark metric?
Am Montag, 29. Januar 2001 04:46 schrieb Jens Axboe:
> On Mon, Jan 29 2001, Dieter Nützel wrote:
> > I have pre11 running with Andrea's suggested fix.
> >
> > high_queued_sectors = total_ram / 3;
> > low_queued_sectors = high_queued_sectors / 2;
> > if (low_queued_sectors < 0)
> > low_queued_sectors = total_ram / 2;
> >
> > /*
> > * for big RAM machines (>= 384MB), use more for I/O
> > */
> > /*
> > if (total_ram >= MB(384)) {
> > high_queued_sectors = (total_ram * 4) / 5;
> > low_queued_sectors = high_queued_sectors - MB(128);
> > }
> > */
> >
> > Shouldn't it be clean for a 2.4.1 release?
>
> With enough swap the numbers I saw were not conclusive. I promised
> to test which I haven't gotten done yet, I will do this tomorrow
> and make sure we have the right ratios. However, I don't think
> the pre11 numbers are much off - do you have any results?
I have 256 MB RAM and 200 MB swap but nothing of the later was used during
"dbench 48". It was nothing spectacular but a litte bit faster with the above.
Attention: Results only from memory...;-)
Good night.
Dieter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11 / ll_rw_b watermark metric?
I have pre11 running with Andrea's suggested fix.
high_queued_sectors = total_ram / 3;
low_queued_sectors = high_queued_sectors / 2;
if (low_queued_sectors < 0)
low_queued_sectors = total_ram / 2;
/*
* for big RAM machines (>= 384MB), use more for I/O
*/
/*
if (total_ram >= MB(384)) {
high_queued_sectors = (total_ram * 4) / 5;
low_queued_sectors = high_queued_sectors - MB(128);
}
*/
Shouldn't it be clean for a 2.4.1 release?
-Dieter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Am Sonntag, 28. Januar 2001 22:46 schrieb Linus Torvalds: > On Sun, 28 Jan 2001, Dieter Nützel wrote: > > > I just uploaded it to kernel.org, and I expect that I'll do the final > > > 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that > > > the pre-kernel works for you.. > > > > Hello Linus, > > > > can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release > > updated: 1-25-2001) in 2.4.1 final? > > Does it fix stuff? Andrew? I am the loser :-( 2.4.1-pre10 (with Andrew's ACPI fixes included) and 2.4.1-pre11 + 1-25-2001 patch bring back the pppd slowdown on my system. 2.4.1-pre9 was fine... AMD K7 MSI MS-6167 Rev. 1.0B (Irongate C4) -Dieter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
> I just uploaded it to kernel.org, and I expect that I'll do the final > 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the > pre-kernel works for you.. Hello Linus, can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release updated: 1-25-2001) in 2.4.1 final? ftp://download.intel.com/technology/iapc/acpi/downloads/acpica-linux-20010125.tar.gz) Thanks, Dieter BTW Have a nice trip. -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
I just uploaded it to kernel.org, and I expect that I'll do the final 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the pre-kernel works for you.. Hello Linus, can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release updated: 1-25-2001) in 2.4.1 final? ftp://download.intel.com/technology/iapc/acpi/downloads/acpica-linux-20010125.tar.gz) Thanks, Dieter BTW Have a nice trip. -- Dieter Ntzel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Klln-Strae 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Am Sonntag, 28. Januar 2001 22:46 schrieb Linus Torvalds: On Sun, 28 Jan 2001, Dieter Ntzel wrote: I just uploaded it to kernel.org, and I expect that I'll do the final 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the pre-kernel works for you.. Hello Linus, can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release updated: 1-25-2001) in 2.4.1 final? Does it fix stuff? Andrew? I am the loser :-( 2.4.1-pre10 (with Andrew's ACPI fixes included) and 2.4.1-pre11 + 1-25-2001 patch bring back the pppd slowdown on my system. 2.4.1-pre9 was fine... AMD K7 MSI MS-6167 Rev. 1.0B (Irongate C4) -Dieter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11 / ll_rw_b watermark metric?
I have pre11 running with Andrea's suggested fix.
high_queued_sectors = total_ram / 3;
low_queued_sectors = high_queued_sectors / 2;
if (low_queued_sectors 0)
low_queued_sectors = total_ram / 2;
/*
* for big RAM machines (= 384MB), use more for I/O
*/
/*
if (total_ram = MB(384)) {
high_queued_sectors = (total_ram * 4) / 5;
low_queued_sectors = high_queued_sectors - MB(128);
}
*/
Shouldn't it be clean for a 2.4.1 release?
-Dieter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11 / ll_rw_b watermark metric?
Am Montag, 29. Januar 2001 04:46 schrieb Jens Axboe:
On Mon, Jan 29 2001, Dieter Ntzel wrote:
I have pre11 running with Andrea's suggested fix.
high_queued_sectors = total_ram / 3;
low_queued_sectors = high_queued_sectors / 2;
if (low_queued_sectors 0)
low_queued_sectors = total_ram / 2;
/*
* for big RAM machines (= 384MB), use more for I/O
*/
/*
if (total_ram = MB(384)) {
high_queued_sectors = (total_ram * 4) / 5;
low_queued_sectors = high_queued_sectors - MB(128);
}
*/
Shouldn't it be clean for a 2.4.1 release?
With enough swap the numbers I saw were not conclusive. I promised
to test which I haven't gotten done yet, I will do this tomorrow
and make sure we have the right ratios. However, I don't think
the pre11 numbers are much off - do you have any results?
I have 256 MB RAM and 200 MB swap but nothing of the later was used during
"dbench 48". It was nothing spectacular but a litte bit faster with the above.
Attention: Results only from memory...;-)
Good night.
Dieter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5 / test13-pre7
Hello Rik, I did some more benchmarks on this --- puh, took me some time...:-) Test machine: 256 MB, K7 550 SlotA, SCSI, IDE, ReiserFS 3.6.23, Blocksize=4K Test: dbench 48 2.4.0-test13-pre5 + Rik's VM fix #2 /dev/sda7: Timing buffered disk reads: 64 MB in 6.07 seconds = 10.54 MB/sec Throughput 7.54785 MB/sec (NB=9.43482 MB/sec 75.4785 MBit/sec) 41.200u 95.870s 13:59.50 16.3% 0+0k 0+0io 1797pf+0w -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations Throughput 7.7981 MB/sec (NB=9.74762 MB/sec 77.981 MBit/sec) 42.180u 96.620s 13:32.54 17.0% 0+0k 0+0io 1799pf+0w -- /dev/hdc1: Timing buffered disk reads: 64 MB in 2.89 seconds = 22.15 MB/sec Throughput 9.4113 MB/sec (NB=11.7641 MB/sec 94.113 MBit/sec) 36.990u 117.720s 11:13.24 22.9% 0+0k 0+0io 1505pf+0w -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations Throughput 10.254 MB/sec (NB=12.8175 MB/sec 102.54 MBit/sec) 36.620u 112.870s 10:17.91 24.1% 0+0k 0+0io 1505pf+0w *** 2.4.0-test13-pre7 /dev/sda7: Timing buffered disk reads: 64 MB in 6.07 seconds = 10.54 MB/sec Throughput 9.61382 MB/sec (NB=12.0173 MB/sec 96.1382 MBit/sec) 43.950u 96.790s 10:59.06 21.3% 0+0k 0+0io 1746pf+0w -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations Throughput 10.8312 MB/sec (NB=13.539 MB/sec 108.312 MBit/sec) 44.510u 93.000s 9:44.99 23.5% 0+0k 0+0io 1795pf+0w - /dev/hdc1: Timing buffered disk reads: 64 MB in 2.89 seconds = 22.15 MB/sec Throughput 12.3312 MB/sec (NB=15.414 MB/sec 123.312 MBit/sec) 35.220u 112.630s 8:33.83 28.7% 0+0k 0+0io 1505pf+0w -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations Throughput 14.4331 MB/sec (NB=18.0414 MB/sec 144.331 MBit/sec) 36.060u 119.760s 7:19.00 35.4% 0+0k 0+0io 1505pf+0w Addition: Your fix show some 'bad' swap behavior on my 'normal' load (3D medical visualization). It do some 'little' swap out and in. Mostly the (not needed?) swap in hurts performance. A little 'cp -a X11R6 X11R6-new' take more than 2 times longer. If my system hits the 'ZERO swap wall' the currently running process (render) abort immediately and restart. With test13-pre7 it runs several times longer (render generates some more frames) but then load goes up to 10 and render would be killed. SunWave1>cat /proc/version Linux version 2.4.0-test13-pre7 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Sat Dec 30 22:13:04 CET 2000 SunWave1>free -t total used free sharedbuffers cached Mem:255728 164980 90748 0 34160 46488 -/+ buffers/cache: 84332 171396 Swap: 200772 8 200764 Total: 456500 164988 291512 Happy New Year! I'll be back on Monday. -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre6 weird with tdfx.o
> J Sloan wrote: > > > Frank Jacobberger wrote: > > > > > This is a first for tdfx.o not loading with XFree 4.01. > > > > > > All prior kernel build through test13-pre5 would load just fine... > > > > > > Strange... > > > > Very strange - others on this list, self included, > > have reported something a bit different: > > > > tdfx.o has not loaded in any kernel since -test12. It haven't loaded since test13-pre1 for me. Only the 'module version' was broken. Last test12-pre7 was fine, here. It was introduced with the Makefile cleanups. [snip] > Hi, > > This is lets it load. The same missing symbols happen with mga as well... > This is from a patch posted here two weeks ago: > > --- linux/drivers/char/drm/drmP.oldThu Dec 28 16:27:34 2000 > +++ linux/drivers/char/drm/drmP.hSat Dec 23 13:57:08 2000 > @@ -40,6 +40,7 @@ > #include > #endif /* __alpha__ */ > #include > +#include > #include > #include > #include > > Not sure if this is more than a temporay fix though. > > Ed Tomlins [snip] I think this patch is very fine. It works here without a hitch. Rik? > > The makefile changes have broken it. > > > > Are you certain tdfx.o loads for you in prior -test13 > > versions? If so, that would be a most disturbing > > development... > > > > jjs > > Yes your right... I just haven't noticed... Why doesn't someone fix it? > > Frank I am involved a little bit into the DRI development and I think it is because all the DRI guys (VA Linux) especially Rik Faith are out for vacation...:-) Happy New Year! -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre6 weird with tdfx.o
J Sloan wrote: Frank Jacobberger wrote: This is a first for tdfx.o not loading with XFree 4.01. All prior kernel build through test13-pre5 would load just fine... Strange... Very strange - others on this list, self included, have reported something a bit different: tdfx.o has not loaded in any kernel since -test12. It haven't loaded since test13-pre1 for me. Only the 'module version' was broken. Last test12-pre7 was fine, here. It was introduced with the Makefile cleanups. [snip] Hi, This is lets it load. The same missing symbols happen with mga as well... This is from a patch posted here two weeks ago: --- linux/drivers/char/drm/drmP.oldThu Dec 28 16:27:34 2000 +++ linux/drivers/char/drm/drmP.hSat Dec 23 13:57:08 2000 @@ -40,6 +40,7 @@ #include asm/current.h #endif /* __alpha__ */ #include linux/config.h +#include linux/modversions.h #include linux/module.h #include linux/kernel.h #include linux/miscdevice.h Not sure if this is more than a temporay fix though. Ed Tomlins [snip] I think this patch is very fine. It works here without a hitch. Rik? The makefile changes have broken it. Are you certain tdfx.o loads for you in prior -test13 versions? If so, that would be a most disturbing development... jjs Yes your right... I just haven't noticed... Why doesn't someone fix it? Frank I am involved a little bit into the DRI development and I think it is because all the DRI guys (VA Linux) especially Rik Faith are out for vacation...:-) Happy New Year! -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5 / test13-pre7
Hello Rik, I did some more benchmarks on this --- puh, took me some time...:-) Test machine: 256 MB, K7 550 SlotA, SCSI, IDE, ReiserFS 3.6.23, Blocksize=4K Test: dbench 48 2.4.0-test13-pre5 + Rik's VM fix #2 /dev/sda7: Timing buffered disk reads: 64 MB in 6.07 seconds = 10.54 MB/sec Throughput 7.54785 MB/sec (NB=9.43482 MB/sec 75.4785 MBit/sec) 41.200u 95.870s 13:59.50 16.3% 0+0k 0+0io 1797pf+0w -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations Throughput 7.7981 MB/sec (NB=9.74762 MB/sec 77.981 MBit/sec) 42.180u 96.620s 13:32.54 17.0% 0+0k 0+0io 1799pf+0w -- /dev/hdc1: Timing buffered disk reads: 64 MB in 2.89 seconds = 22.15 MB/sec Throughput 9.4113 MB/sec (NB=11.7641 MB/sec 94.113 MBit/sec) 36.990u 117.720s 11:13.24 22.9% 0+0k 0+0io 1505pf+0w -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations Throughput 10.254 MB/sec (NB=12.8175 MB/sec 102.54 MBit/sec) 36.620u 112.870s 10:17.91 24.1% 0+0k 0+0io 1505pf+0w *** 2.4.0-test13-pre7 /dev/sda7: Timing buffered disk reads: 64 MB in 6.07 seconds = 10.54 MB/sec Throughput 9.61382 MB/sec (NB=12.0173 MB/sec 96.1382 MBit/sec) 43.950u 96.790s 10:59.06 21.3% 0+0k 0+0io 1746pf+0w -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations Throughput 10.8312 MB/sec (NB=13.539 MB/sec 108.312 MBit/sec) 44.510u 93.000s 9:44.99 23.5% 0+0k 0+0io 1795pf+0w - /dev/hdc1: Timing buffered disk reads: 64 MB in 2.89 seconds = 22.15 MB/sec Throughput 12.3312 MB/sec (NB=15.414 MB/sec 123.312 MBit/sec) 35.220u 112.630s 8:33.83 28.7% 0+0k 0+0io 1505pf+0w -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations Throughput 14.4331 MB/sec (NB=18.0414 MB/sec 144.331 MBit/sec) 36.060u 119.760s 7:19.00 35.4% 0+0k 0+0io 1505pf+0w Addition: Your fix show some 'bad' swap behavior on my 'normal' load (3D medical visualization). It do some 'little' swap out and in. Mostly the (not needed?) swap in hurts performance. A little 'cp -a X11R6 X11R6-new' take more than 2 times longer. If my system hits the 'ZERO swap wall' the currently running process (render) abort immediately and restart. With test13-pre7 it runs several times longer (render generates some more frames) but then load goes up to 10 and render would be killed. SunWave1cat /proc/version Linux version 2.4.0-test13-pre7 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Sat Dec 30 22:13:04 CET 2000 SunWave1free -t total used free sharedbuffers cached Mem:255728 164980 90748 0 34160 46488 -/+ buffers/cache: 84332 171396 Swap: 200772 8 200764 Total: 456500 164988 291512 Happy New Year! I'll be back on Monday. -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5
Am Freitag, 29. Dezember 2000 14:38 schrieben Sie: > On Fri, 29 Dec 2000, Dieter Nützel wrote: > > your patch didn't apply clean. > > Have you another version? > > It should apply just fine. What error messages did > patch give ? > Applied #2 against my running 2.4.0-test13-pre5 + ReiserFS 3.6.23 tree and a clean test13-pre5 (test12 + test13-pre5). Same for both of them: SunWave1>patch -p0 -E -N http://www.tux.org/lkml/
Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5
Am Freitag, 29. Dezember 2000 14:38 schrieben Sie: On Fri, 29 Dec 2000, Dieter Nützel wrote: your patch didn't apply clean. Have you another version? It should apply just fine. What error messages did patch give ? Applied #2 against my running 2.4.0-test13-pre5 + ReiserFS 3.6.23 tree and a clean test13-pre5 (test12 + test13-pre5). Same for both of them: SunWave1patch -p0 -E -N patches/2.4.0-test13-pre5-VM-fix patching file `linux-2.4.0-test13-pre5/mm/filemap.c' Hunk #1 FAILED at 1912. Hunk #2 FAILED at 2438. Hunk #3 FAILED at 2448. Hunk #4 FAILED at 2493. 4 out of 4 hunks FAILED -- saving rejects to linux-2.4.0-test13-pre5/mm/filemap.c.rej patching file `linux-2.4.0-test13-pre5/mm/memory.c' Hunk #1 FAILED at 1198. 1 out of 1 hunk FAILED -- saving rejects to linux-2.4.0-test13-pre5/mm/memory.c.rej patching file `linux-2.4.0-test13-pre5/mm/vmscan.c' Hunk #1 FAILED at 49. Hunk #2 FAILED at 59. Hunk #3 FAILED at 92. Hunk #4 FAILED at 108. Hunk #5 FAILED at 159. Hunk #6 FAILED at 200. Hunk #7 FAILED at 271. Hunk #8 FAILED at 290. Hunk #9 FAILED at 310. Hunk #10 succeeded at 390 with fuzz 2. Hunk #11 FAILED at 430. Hunk #12 FAILED at 575. Hunk #13 FAILED at 586. Hunk #14 FAILED at 618. Hunk #15 FAILED at 932. Hunk #16 FAILED at 944. Hunk #17 FAILED at 953. Hunk #18 FAILED at 972. Hunk #19 succeeded at 1007 with fuzz 2. Hunk #20 succeeded at 1182 with fuzz 2. 17 out of 20 hunks FAILED -- saving rejects to linux-2.4.0-test13-pre5/mm/vmscan.c.rej patching file `linux-2.4.0-test13-pre5/include/linux/mm.h' Hunk #1 succeeded at 460 with fuzz 2. patching file `linux-2.4.0-test13-pre5/include/linux/swap.h' filemap.c : offset of 3 lines needed memory.c : dito vmscan.c : dito Now, I hacked it by 'hand' and got it running. I did dbench and saw nearly same results then Daniel Phillips But my disk is to small. Some writes failed...:-( Test machine: 256 MB, Athlon 550 SlotA, SCSI, ReiserFS 3.6.23, Blocksize=4K Test: dbench 48 Throughput: 10.89 MB/sec Elapsed Time: 9 min 47 secs "Guten Rutsch in's neue Jahr!" :-) -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-preX: DRM (tdfx.o) unresolved symbols fixed?
Am Donnerstag, 28. Dezember 2000 17:40 schrieb Tony Hoyle: > Dieter Nützel wrote: > > Am Mittwoch, 27. Dezember 2000 11:07 schrieb Nils Philippsen: > > > Hi all, > > > > > > On Wed, 27 Dec 2000, Dieter [iso-8859-1] Nützel wrote: > > > > I got this since test13-pre1 (pre4, now): > > > > > > > > SunWave1>depmod -e > > > > depmod: *** Unresolved symbols in > > > > /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o > > > > > > [snipped] > > > > > > > Something missing in the 'new' drm/Makefile? > > This is a temporary fix: > > --- drmP.old Thu Dec 28 16:27:34 2000 > +++ drmP.hSat Dec 23 13:57:08 2000 > @@ -40,6 +40,7 @@ > #include > #endif /* __alpha__ */ > #include > +#include > #include > #include > #include If I compile agpgart and tdfx directly into the kernel, it works for me, too. Thanks! Dieter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-preX: DRM (tdfx.o) unresolved symbols fixed?
Am Donnerstag, 28. Dezember 2000 17:40 schrieb Tony Hoyle: Dieter Nützel wrote: Am Mittwoch, 27. Dezember 2000 11:07 schrieb Nils Philippsen: Hi all, On Wed, 27 Dec 2000, Dieter [iso-8859-1] Nützel wrote: I got this since test13-pre1 (pre4, now): SunWave1depmod -e depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o [snipped] Something missing in the 'new' drm/Makefile? This is a temporary fix: --- drmP.old Thu Dec 28 16:27:34 2000 +++ drmP.hSat Dec 23 13:57:08 2000 @@ -40,6 +40,7 @@ #include asm/current.h #endif /* __alpha__ */ #include linux/config.h +#include linux/modversions.h #include linux/module.h #include linux/kernel.h #include linux/miscdevice.h If I compile agpgart and tdfx directly into the kernel, it works for me, too. Thanks! Dieter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-preX: DRM (tdfx.o) unresolved symbols fixed?
Am Mittwoch, 27. Dezember 2000 11:07 schrieb Nils Philippsen: > Hi all, > > On Wed, 27 Dec 2000, Dieter [iso-8859-1] Nützel wrote: > > I got this since test13-pre1 (pre4, now): > > > > SunWave1>depmod -e > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o > > [snipped] > > > Something missing in the 'new' drm/Makefile? > > From the test13-pre4 patch, the only difference I can see is that shared > code is now in drmlib.a instead of the object files being linked > individually for each drm module. Yep, I saw this, too. > If I do `nm tdfx.o|grep printk`, with test12 I get only this: > > U printk_R1b7d4074 dito SunWave1>cd ../../../../../2.4.0-test12-pre7/kernel/drivers/char/drm/ SunWave1>nm tdfx.o | grep printk U printk_R1b7d4074 > with test13-pre4 on my home machine, I get the mangled symbol name plus a > non-mangled one, both unresolved, maybe that causes problems. SunWave1>cd ../../../../../2.4.0-test13-pre4/kernel/drivers/char/drm/ SunWave1>nm tdfx.o | grep printk U printk U printk_R1b7d4074 But the strange thing is this: SunWave1>depmod -e depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o depmod: remap_page_range depmod: _mmx_memcpy depmod: __wake_up depmod: mtrr_add depmod: __generic_copy_from_user depmod: schedule [snip] -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-preX: DRM (tdfx.o) unresolved symbols fixed?
Am Mittwoch, 27. Dezember 2000 11:07 schrieb Nils Philippsen: Hi all, On Wed, 27 Dec 2000, Dieter [iso-8859-1] Nützel wrote: I got this since test13-pre1 (pre4, now): SunWave1depmod -e depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o [snipped] Something missing in the 'new' drm/Makefile? From the test13-pre4 patch, the only difference I can see is that shared code is now in drmlib.a instead of the object files being linked individually for each drm module. Yep, I saw this, too. If I do `nm tdfx.o|grep printk`, with test12 I get only this: U printk_R1b7d4074 dito SunWave1cd ../../../../../2.4.0-test12-pre7/kernel/drivers/char/drm/ SunWave1nm tdfx.o | grep printk U printk_R1b7d4074 with test13-pre4 on my home machine, I get the mangled symbol name plus a non-mangled one, both unresolved, maybe that causes problems. SunWave1cd ../../../../../2.4.0-test13-pre4/kernel/drivers/char/drm/ SunWave1nm tdfx.o | grep printk U printk U printk_R1b7d4074 But the strange thing is this: SunWave1depmod -e depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o depmod: remap_page_range depmod: _mmx_memcpy depmod: __wake_up depmod: mtrr_add depmod: __generic_copy_from_user depmod: schedule [snip] -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test13-preX: DRM (tdfx.o) unresolved symbols fixed?
Hello to all of you, I got this since test13-pre1 (pre4, now): SunWave1>depmod -e depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o depmod: remap_page_range depmod: _mmx_memcpy depmod: __wake_up depmod: mtrr_add depmod: __generic_copy_from_user depmod: schedule depmod: kmalloc depmod: si_meminfo depmod: create_proc_entry depmod: inter_module_put depmod: __get_free_pages depmod: boot_cpu_data depmod: inter_module_get depmod: remove_wait_queue depmod: high_memory depmod: iounmap depmod: free_pages depmod: __ioremap depmod: del_timer depmod: interruptible_sleep_on depmod: __pollwait depmod: kfree depmod: remove_proc_entry depmod: pci_find_slot depmod: kill_fasync depmod: fasync_helper depmod: add_wait_queue depmod: do_mmap_pgoff depmod: mem_map depmod: sprintf depmod: jiffies depmod: printk depmod: add_timer depmod: irq_stat depmod: __generic_copy_to_user Something missing in the 'new' drm/Makefile? Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test13-preX: DRM (tdfx.o) unresolved symbols fixed?
Hello to all of you, I got this since test13-pre1 (pre4, now): SunWave1depmod -e depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o depmod: remap_page_range depmod: _mmx_memcpy depmod: __wake_up depmod: mtrr_add depmod: __generic_copy_from_user depmod: schedule depmod: kmalloc depmod: si_meminfo depmod: create_proc_entry depmod: inter_module_put depmod: __get_free_pages depmod: boot_cpu_data depmod: inter_module_get depmod: remove_wait_queue depmod: high_memory depmod: iounmap depmod: free_pages depmod: __ioremap depmod: del_timer depmod: interruptible_sleep_on depmod: __pollwait depmod: kfree depmod: remove_proc_entry depmod: pci_find_slot depmod: kill_fasync depmod: fasync_helper depmod: add_wait_queue depmod: do_mmap_pgoff depmod: mem_map depmod: sprintf depmod: jiffies depmod: printk depmod: add_timer depmod: irq_stat depmod: __generic_copy_to_user Something missing in the 'new' drm/Makefile? Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
> List: linux-kernel > Subject: Re: test13-pre3 woes > From: Peter Samuelson <[EMAIL PROTECTED]> > Date: 2000-12-18 9:19:13 > [Download message RAW] > > > [J Sloan] > > The module now compiles and gets installed - > > Unfortunately, attempting to load it does not go well: > > > > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range > > kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up > > kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add > > kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user > > kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule > > kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc > > kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo > > Those symbols are rather generic and rather important. Sounds like a > generic module problem. Do other modules load? Does your kernel use > MODVERSIONS? (This module apparently doesn't.) Are you using a recent > version of modutils? > > Puzzled. Maybe Keith Owens knows something. > > Peter I got this, too. The one liner send here on lkm seems to be not enough. Even Alan's ac1/2 did not do the trick. The 'new' Linux makefile changes brake this stuff. It works before these changes. So Rik any comments? Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
List: linux-kernel Subject: Re: test13-pre3 woes From: Peter Samuelson [EMAIL PROTECTED] Date: 2000-12-18 9:19:13 [Download message RAW] [J Sloan] The module now compiles and gets installed - Unfortunately, attempting to load it does not go well: kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo Those symbols are rather generic and rather important. Sounds like a generic module problem. Do other modules load? Does your kernel use MODVERSIONS? (This module apparently doesn't.) Are you using a recent version of modutils? Puzzled. Maybe Keith Owens knows something. Peter I got this, too. The one liner send here on lkm seems to be not enough. Even Alan's ac1/2 did not do the trick. The 'new' Linux makefile changes brake this stuff. It works before these changes. So Rik any comments? Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test11: unresolved symbols
Hello all, I played around with the 'new' masquerading/network stuff for the first time. xDSL is coming to me in some days...:-) I get the following unresolved symbols with pure 2.4.0-test11. Am I missing something? depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_conntrack.o depmod: nf_unregister_hook depmod: nf_unregister_sockopt depmod: nf_register_hook depmod: nf_register_sockopt depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_tables.o depmod: nf_unregister_sockopt depmod: nf_register_sockopt depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/iptable_filter.o depmod: nf_unregister_hook depmod: nf_register_hook depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/iptable_nat.o depmod: nf_unregister_hook depmod: nf_register_hook depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv6/ipv6.o depmod: rtnetlink_links depmod: sk_run_filter depmod: nf_hooks depmod: __rta_fill depmod: netlink_set_err depmod: nf_setsockopt depmod: netlink_broadcast depmod: rtnetlink_put_metrics depmod: nf_getsockopt depmod: netlink_unicast depmod: rtnl depmod: nf_hook_slow depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv6/netfilter/ip6_tables.o depmod: nf_unregister_sockopt depmod: nf_register_sockopt depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv6/netfilter/ip6table_filter.o depmod: nf_unregister_hook depmod: nf_register_hook depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/packet/af_packet.o depmod: sk_run_filter Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test11: unresolved symbols
Hello all, I played around with the 'new' masquerading/network stuff for the first time. xDSL is coming to me in some days...:-) I get the following unresolved symbols with pure 2.4.0-test11. Am I missing something? depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_conntrack.o depmod: nf_unregister_hook depmod: nf_unregister_sockopt depmod: nf_register_hook depmod: nf_register_sockopt depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/ip_tables.o depmod: nf_unregister_sockopt depmod: nf_register_sockopt depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/iptable_filter.o depmod: nf_unregister_hook depmod: nf_register_hook depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv4/netfilter/iptable_nat.o depmod: nf_unregister_hook depmod: nf_register_hook depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv6/ipv6.o depmod: rtnetlink_links depmod: sk_run_filter depmod: nf_hooks depmod: __rta_fill depmod: netlink_set_err depmod: nf_setsockopt depmod: netlink_broadcast depmod: rtnetlink_put_metrics depmod: nf_getsockopt depmod: netlink_unicast depmod: rtnl depmod: nf_hook_slow depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv6/netfilter/ip6_tables.o depmod: nf_unregister_sockopt depmod: nf_register_sockopt depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/ipv6/netfilter/ip6table_filter.o depmod: nf_unregister_hook depmod: nf_register_hook depmod: *** Unresolved symbols in /lib/modules/2.4.0-test11/kernel/net/packet/af_packet.o depmod: sk_run_filter Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0.-test10: kernel oops - mount / tdfx.o related
Hello Rik, I've got a kernel oops with the 'latest' linux kernel and the DRI. CD mounting was involved. ksymoops 2.3.4 on i686 2.4.0-test10. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test10/ (default) -m /boot/System.map (specified) Nov 4 18:40:05 SunWave1 kernel: Unable to handle kernel paging request at virtual address d0c353f3 Nov 4 18:40:05 SunWave1 kernel: d0c353f3 Nov 4 18:40:05 SunWave1 kernel: *pde = 0c291063 Nov 4 18:40:05 SunWave1 kernel: Oops: Nov 4 18:40:05 SunWave1 kernel: CPU:0 Nov 4 18:40:05 SunWave1 kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Nov 4 18:40:05 SunWave1 kernel: EFLAGS: 00010296 Nov 4 18:40:05 SunWave1 kernel: eax: c147a2a8 ebx: cd3c3bd4 ecx: 0001 edx: c147a280 Nov 4 18:40:05 SunWave1 kernel: esi: cc6e2214 edi: cbc3dd84 ebp: cd3c3b80 esp: cbc3dd34 Nov 4 18:40:05 SunWave1 kernel: ds: 0018 es: 0018 ss: 0018 Nov 4 18:40:05 SunWave1 kernel: Process mount (pid: 325, stackpage=cbc3d000) Nov 4 18:40:05 SunWave1 kernel: Stack: cd3c3b80 cbc3dd84 0bb8 0003 0002 cc6e2214 Nov 4 18:40:05 SunWave1 kernel:d0c36d20 c147a280 d0c35b12 cbc3dd84 Nov 4 18:40:05 SunWave1 kernel: 0003 001b 0003 292e d0c2b3e2 Nov 4 18:40:05 SunWave1 kernel: Call Trace: [] [] [] [bread+24/112] [] [blkdev_get+262/336] [do_no_page+168/272] Nov 4 18:40:05 SunWave1 kernel: Code: Bad EIP value. >>EIP; d0c353f3 <[tdfx].bss.end+3f538/60041a5> <= Trace; d0c36d20 <[tdfx].bss.end+40e65/60041a5> Trace; d0c35b12 <[tdfx].bss.end+3fc57/60041a5> Trace; d0c2b3e2 <[tdfx].bss.end+35527/60041a5> Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0.-test10: kernel oops - mount / tdfx.o related
Hello Rik, I've got a kernel oops with the 'latest' linux kernel and the DRI. CD mounting was involved. ksymoops 2.3.4 on i686 2.4.0-test10. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test10/ (default) -m /boot/System.map (specified) Nov 4 18:40:05 SunWave1 kernel: Unable to handle kernel paging request at virtual address d0c353f3 Nov 4 18:40:05 SunWave1 kernel: d0c353f3 Nov 4 18:40:05 SunWave1 kernel: *pde = 0c291063 Nov 4 18:40:05 SunWave1 kernel: Oops: Nov 4 18:40:05 SunWave1 kernel: CPU:0 Nov 4 18:40:05 SunWave1 kernel: EIP:0010:[d0c353f3] Using defaults from ksymoops -t elf32-i386 -a i386 Nov 4 18:40:05 SunWave1 kernel: EFLAGS: 00010296 Nov 4 18:40:05 SunWave1 kernel: eax: c147a2a8 ebx: cd3c3bd4 ecx: 0001 edx: c147a280 Nov 4 18:40:05 SunWave1 kernel: esi: cc6e2214 edi: cbc3dd84 ebp: cd3c3b80 esp: cbc3dd34 Nov 4 18:40:05 SunWave1 kernel: ds: 0018 es: 0018 ss: 0018 Nov 4 18:40:05 SunWave1 kernel: Process mount (pid: 325, stackpage=cbc3d000) Nov 4 18:40:05 SunWave1 kernel: Stack: cd3c3b80 cbc3dd84 0bb8 0003 0002 cc6e2214 Nov 4 18:40:05 SunWave1 kernel:d0c36d20 c147a280 d0c35b12 cbc3dd84 Nov 4 18:40:05 SunWave1 kernel: 0003 001b 0003 292e d0c2b3e2 Nov 4 18:40:05 SunWave1 kernel: Call Trace: [d0c36d20] [d0c35b12] [d0c2b3e2] [bread+24/112] [d0c2b2f8] [blkdev_get+262/336] [do_no_page+168/272] Nov 4 18:40:05 SunWave1 kernel: Code: Bad EIP value. EIP; d0c353f3 [tdfx].bss.end+3f538/60041a5 = Trace; d0c36d20 [tdfx].bss.end+40e65/60041a5 Trace; d0c35b12 [tdfx].bss.end+3fc57/60041a5 Trace; d0c2b3e2 [tdfx].bss.end+35527/60041a5 Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Is 2.4.0 ready for the AMD 760 MP dual Athlon chip set?
Hello, AMD has rolled out the new AMD 760 MP dual Athlon chip set at the 2000 Microprocessor Forum. Here are the links: http://www.amd.com/news/prodpr/20165.html http://www.amd.com/news/virtualpress/mpf/richheyepres.pdf Someone working on support for it? The chip set seems like the Alpha Tsunami to me. Thanks for response. Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Is 2.4.0 ready for the AMD 760 MP dual Athlon chip set?
Hello, AMD has rolled out the new AMD 760 MP dual Athlon chip set at the 2000 Microprocessor Forum. Here are the links: http://www.amd.com/news/prodpr/20165.html http://www.amd.com/news/virtualpress/mpf/richheyepres.pdf Someone working on support for it? The chip set seems like the Alpha Tsunami to me. Thanks for response. Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
