2.6.13 PowerBook boot hang (was Re: 2.6.13-rc7-git2 crashes on iBook)
Andreas Schwab <[EMAIL PROTECTED]> writes:
> The last change to drivers/pci/setup-res.c (Ignore disabled ROM resources
> at setup) is breaking radeonfb on iBook G3 (with Radeon Mobility M6 LY).
> It crashes in pci_map_rom when called from radeonfb_map_ROM. This is
> probably a dormant bug that was just uncovered by the change.
2.6.13 hangs on boot on my PowerBook 5.4, reverting the disabled ROM
patch (appended for confirmation) fixes it. 2.6.13-rc7 was fine.
diff-tree 755528c860b05fcecda1c88a2bdaffcb50760a7f (from
26aad69e3dd854abe9028ca873fb40b410a39dd7)
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Fri Aug 26 10:49:22 2005 -0700
Ignore disabled ROM resources at setup
Writing even a disabled value seems to mess up some matrox graphics
cards. It may be a card-related issue, but we may also be writing
reserved low bits in the result.
This was a fall-out of switching x86 over to the generic PCI resource
allocation code, and needs more debugging. In particular, the old x86
code defaulted to not doing any resource allocations at all for ROM
resources.
In the meantime, this has been reported to make X happier by Helge
Hafting <[EMAIL PROTECTED]>.
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -53,7 +53,9 @@ pci_update_resource(struct pci_dev *dev,
if (resno < 6) {
reg = PCI_BASE_ADDRESS_0 + 4 * resno;
} else if (resno == PCI_ROM_RESOURCE) {
- new |= res->flags & IORESOURCE_ROM_ENABLE;
+ if (!(res->flags & IORESOURCE_ROM_ENABLE))
+ return;
+ new |= PCI_ROM_ADDRESS_ENABLE;
reg = dev->rom_base_reg;
} else {
/* Hmm, non-standard resource. */
-
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.6.12-rc2-mm1: inotify and directory removal
Using your glib sample thingy from http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/ $ mkdir snozzberries Event on wd=0: snozzberries, a directory, was created $ rmdir snozzberries Event on wd=0: snozzberries, a directory, was deleted $ mkdir snozzberries Event on wd=0: bunneh, a directory, was created $ rm -r snozzberries Event on wd=0: The watch was opened Also seen, watching a directory after some other traffic: $ mkdir snozzberries Event on wd=0: snozzberries, a directory, was created $ rm -r snozzberries Event on wd=0: The watch was opened Event on wd=0: was closed (was not writable) If I use absolute paths the rmdir/mkdir case is the same. However: $ mkdir ~/tmp/snozzberries Event on wd=0: snozzberries, a directory, was created $ rm -r ~/tmp/snozzberries Event on wd=0: snozzberries was opened -- Dag vijandelijk luchtschip de huismeester is dood - 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/
PCMCIA Oops (was Re: 2.6.12-rc1-mm3)
On a PowerBook5.4 I get the below when I insert the PCMCIA card or boot with it inserted; however, if I boot with no card inserted, sleep-resume and insert the card it works fine. Similar with 2.6.12-rc1-mm1; not sure why I didn't notice until now, since I happily used it for six days or so, PCMCIA and all, although there was *some* PCMCIA-related issue I failed to note and cannot now recall. Yenta: CardBus bridge found at 0001:10:13.0 [:] Yenta: Enabling burst memory read transactions Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0001:10:13.0, mfunc 0x1002, devctl 0x60 Yenta: ISA IRQ mask 0x, PCI irq 53 Socket status: 3010 pcmcia: I/O behind socket: 0x0 - 0x7f pcmcia: Memory behind socket: 0xf300 - 0xf3ff pcmcia: Memory behind socket: 0x8000 - 0xafff cs: memory probe 0x8000-0xafff:Machine check in kernel mode. Caused by (from SRR1=149030): Transfer error ack signal Oops: machine check, sig: 7 [#1] NIP: F20CEC90 LR: F20CEC64 SP: EF8F3BE0 REGS: ef8f3b30 TRAP: 0200Not tainted MSR: 00149030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c12966a0[805] 'modprobe' THREAD: ef8f2000 Last syscall: 128 GPR00: 0060 EF8F3BE0 C12966A0 F103C000 EF8F9880 0002 EF8F3C5A GPR08: C04B6370 F103D000 1000 22002488 1001E284 10017070 GPR16: C1225D40 3000 GPR24: EF8F3C5A 0021 0002 C12D282C 0002 EF8F3C5A NIP [f20cec90] pcmcia_read_cis_mem+0x184/0x1c0 [pcmcia_core] LR [f20cec64] pcmcia_read_cis_mem+0x158/0x1c0 [pcmcia_core] Call trace: [f20cefa0] read_cis_cache+0x144/0x168 [pcmcia_core] [f20cf668] pccard_get_next_tuple+0x7c/0x2a8 [pcmcia_core] [f20cf378] pccard_get_first_tuple+0x94/0x144 [pcmcia_core] [f20d0fb8] pccard_validate_cis+0x94/0x27c [pcmcia_core] [f106e3c8] readable+0x88/0xa8 [rsrc_nonstatic] [f106e5a0] cis_readable+0xc8/0xe4 [rsrc_nonstatic] [f106e860] do_mem_probe+0x1d0/0x1e8 [rsrc_nonstatic] [f106e8b8] validate_mem+0x40/0x68 [rsrc_nonstatic] [f106e99c] pcmcia_nonstatic_validate_mem+0xbc/0xc8 [rsrc_nonstatic] [f20d134c] pcmcia_validate_mem+0x34/0x38 [pcmcia_core] [f20e39b4] pcmcia_card_add+0x28/0xc0 [pcmcia] [f20e441c] ds_event+0x8c/0xe4 [pcmcia] [f20cda3c] send_event+0x70/0xc8 [pcmcia_core] [f20ce52c] pccard_register_pcmcia+0xac/0xcc [pcmcia_core] [f20e49b4] pcmcia_bus_add_socket+0xa8/0x104 [pcmcia] -- Dag vijandelijk luchtschip de huismeester is dood - 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.6.11-mm4
Andrew Morton <[EMAIL PROTECTED]> writes: > Yes, the pmac cpufreq Kconfig dependencies are being troublesome. > > Roman sent this to Ben and I overnight: > > > From: Roman Zippel <[EMAIL PROTECTED]> > > This completes the Kconfig cleanup for all other archs. CPU_FREQ_TABLE was > moved to drivers/cpufreq/Kconfig and is selected as needed. Seems to do the trick on ppc: with this patch applied, oldconfig results in CONFIG_CPU_FREQ_TABLE=y. -- Dag vijandelijk luchtschip de huismeester is dood - 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.6.11-mm4
Fails to build here: arch/ppc/platforms/built-in.o(.pmac.text+0x6828): In function `flush_disable_caches': : undefined reference to `cpufreq_frequency_table_verify' arch/ppc/platforms/built-in.o(.pmac.text+0x6868): In function `flush_disable_caches': : undefined reference to `cpufreq_frequency_table_target' arch/ppc/platforms/built-in.o(.pmac.text+0x68f0): In function `flush_disable_caches': : undefined reference to `cpufreq_frequency_table_cpuinfo' make: *** [.tmp_vmlinux1] Error 1 This patch makes it work again; there are duplicate CPU_FREQ_TABLE definitions in some arch Kconfigs. Possibly not the Right Thing(tm). [briny(~/build/linux/S11-mm4)] find arch/ -name Kconfig | xargs grep '^config CPU_FREQ_TABLE' arch/sparc64/Kconfig:config CPU_FREQ_TABLE arch/sh/Kconfig:config CPU_FREQ_TABLE arch/ppc/Kconfig:config CPU_FREQ_TABLE arch/x86_64/kernel/cpufreq/Kconfig:config CPU_FREQ_TABLE --- S11-mm4/drivers/cpufreq/Kconfig~2005-03-16 22:12:52.0 + +++ S11-mm4/drivers/cpufreq/Kconfig 2005-03-16 22:37:59.0 + @@ -15,9 +15,6 @@ if CPU_FREQ -config CPU_FREQ_TABLE - def_tristate m - config CPU_FREQ_DEBUG bool "Enable CPUfreq debugging" help -- Dag vijandelijk luchtschip de huismeester is dood - 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.6.11-mm3: machine check on sleep, PowerBook5.4
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > On Sun, 2005-03-13 at 19:07 +0000, Sean Neakums wrote: >> Sean Neakums <[EMAIL PROTECTED]> writes: >> >> > Both patches give me a successful sleep, although I had to alter the >> > second to not #if 0 core99_ata100_enable -- there's another call to >> > that function in pmac_feature.c's set_initial_features(). >> > >> > I will try to gather some power numbers. >> >> With the first patch, charge dropped by 33 over 52 minutes, 0.64/min. >> With the second patch, charge dropped by 65 over 80 minutes, 0.81/min. > > Hi ! With the same initial charge ? The problem is that the drop isn't > really linear... Oh, fiddlesticks, that didn't occur to me. I can redo with overnight sleeps on a full charge, if you like. -- Dag vijandelijk luchtschip de huismeester is dood - 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.6.11-mm3: machine check on sleep, PowerBook5.4
Sean Neakums <[EMAIL PROTECTED]> writes: > Both patches give me a successful sleep, although I had to alter the > second to not #if 0 core99_ata100_enable -- there's another call to > that function in pmac_feature.c's set_initial_features(). > > I will try to gather some power numbers. With the first patch, charge dropped by 33 over 52 minutes, 0.64/min. With the second patch, charge dropped by 65 over 80 minutes, 0.81/min. -- Dag vijandelijk luchtschip de huismeester is dood - 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.6.11-mm3: machine check on sleep, PowerBook5.4
Both patches give me a successful sleep, although I had to alter the second to not #if 0 core99_ata100_enable -- there's another call to that function in pmac_feature.c's set_initial_features(). I will try to gather some power numbers. -- Dag vijandelijk luchtschip de huismeester is dood - 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: DRI breakage, 2.6.11-mm[123]
Dave Jones <[EMAIL PROTECTED]> writes: > On Sun, Mar 13, 2005 at 10:13:49AM +1100, Dave Airlie wrote: > > On Sat, 12 Mar 2005 19:29:20 +0000, Sean Neakums <[EMAIL PROTECTED]> wrote: > > > Sean Neakums <[EMAIL PROTECTED]> writes: > > > > > > > The following happens with 2.6.11-mm[123]. (I didn't have time to > > > > investigate earlier; sorry.) It does not happen with 2.6.11-rc3-mm2 > > > > and 2.6.11. I have tested 2.6.11-mm3 with dri disabled (by not > > > > loading X's dri module) and it also does not happen then. > > > > > > Also happens on 2.6.11-mm3 with bk-drm.patch reverted. > > > > > > To expand on my crappy report, the graphics card is a Radeon 9200: > > > > Wierd the -mm tree has currently very few drm changes over the non-mm > > tree and if reverting bk-drm doesn't help it sounds like something in > > the generic ioctl code may be gone wrong... > > > > Can you try a 2.6.12-bk snapshot.. it may be the multi-head patches > > are buggy > > Could be. Given the other agp problems didn't get spotted in -mm > my confidence in those patches has dropped off somewhat in the > last few days. > > Hopefully it's something simple. Same symptoms with 2.6.11-bk8. -- Dag vijandelijk luchtschip de huismeester is dood - 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.6.11-mm3: machine check on sleep, PowerBook5.4
Machine check in kernel mode. Caused by (from SRR1=149030): Transfer error ack signal Oops: machine check, sig: 7 [#1] TASK = etc. 'pmud' etc. (for registers and such, see: http://flynn.zork.net/~sneakums/pmac-machine-check-on-sleep-2611mm3.jpeg ) Call trace: pmac_ide_pci_suspend pci_device_suspend suspend_device device_suspend 0xc03dd894 0xc03dddb8 0xc03de7cc do_ioctl vfs_ioctl sys_ioctl ret_from_syscall -- Dag vijandelijk luchtschip de huismeester is dood - 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: DRI breakage, 2.6.11-mm[123]
Sean Neakums <[EMAIL PROTECTED]> writes: > The following happens with 2.6.11-mm[123]. (I didn't have time to > investigate earlier; sorry.) It does not happen with 2.6.11-rc3-mm2 > and 2.6.11. I have tested 2.6.11-mm3 with dri disabled (by not > loading X's dri module) and it also does not happen then. Also happens on 2.6.11-mm3 with bk-drm.patch reverted. To expand on my crappy report, the graphics card is a Radeon 9200: :01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) -- Dag vijandelijk luchtschip de huismeester is dood - 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/
DRI breakage, 2.6.11-mm[123]
The following happens with 2.6.11-mm[123]. (I didn't have time to investigate earlier; sorry.) It does not happen with 2.6.11-rc3-mm2 and 2.6.11. I have tested 2.6.11-mm3 with dri disabled (by not loading X's dri module) and it also does not happen then. When I start X, I get a screen full of what looks like random pixels. Apart from the pointer, X seems generally non-functional. The X server (Debian's 4.3.0.dfsg.1-1) is spinning doing the following, apparently indefinitely (fd 5 is /dev/dri/card0): ioctl(5, 0x6444, 0) = -1 EBUSY (Device or resource busy) ioctl(5, 0x6444, 0) = -1 EBUSY (Device or resource busy) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) ioctl(5, 0x6444, 0) = -1 EBUSY (Device or resource busy) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) ioctl(5, 0x6444, 0) = -1 EBUSY (Device or resource busy) ioctl(5, 0x6444, 0) = -1 EBUSY (Device or resource busy) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) ioctl(5, 0x6444, 0) = -1 EBUSY (Device or resource busy) Kernel configuration at http://flynn.zork.net/~sneakums/config-2.6.11-mm3 -- Dag vijandelijk luchtschip de huismeester is dood - 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: rmmod while module is in use
Davide Rossetti <[EMAIL PROTECTED]> writes: > maybe RTFM... > a module: > - char device driver for.. > - a PCI device Setting the 'owner' field of your char device's file_operations structure to THIS_MODULE should be sufficient to enable the kernel to manage the reference count for you. This is the "magic" referred to in linux-os's reply. - 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.6.11-rc3-mm1
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> writes: > On Sat, 05 Feb 2005 11:16:49 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> wrote: >> >> > I tried it two or three times, same result each time. I'll give it a >> > lash with USB disabled. >> >> Also, can you try editing arch/ppc/syslib/open_pic.c, in function >> openpic_resume(), comment out the call to openpic_reset() and let me >> know if that helps... > > Well, maybe I'm to blame this time... > > I've introduced bug in ATAPI Power Management handling, > idedisk_pm_idle shouldn't be done for ATAPI devices. > > Sorry for that, fix attached. With this patch alone and with USB configured out, suspend/resume works. I said earlier that USB didn't seem to be giving problems. When I was trying out the openpic_reset()-removal, I got an Oops on suspend, reproduced below. I then received Bartlomiej's patch, which I applied to a clean 2.6.11-rc3-mm1 tree. Same USB Oops, no suspend. Then I disabled USB, and suspend/resume worked. I can still try the openpic_reset()-removal in a clean tree with USB disabled if you wish. Oops: kernel access of bad area, sig: 11 [#1] NIP: C01FFD2C LR: C01D7A6C SP: EFBB1D80 REGS: efbb1cd0 TRAP: 0300Not tainted MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 0C54, DSISR: 4000 TASK = efb01830[1067] 'pmud' THREAD: efbb Last syscall: 54 GPR00: C01D7A6C EFBB1D80 EFB01830 C114ACC0 0003 FFB9 C048 GPR08: C114ACD8 C03F3B2C 22044484 1001E4DC 1001 1000 GPR16: 1000 C03F C042A6F0 C03F C042A6E8 C043 0003 00100100 GPR24: 00200200 C042A6E0 C043 C043 0003 C114ACC0 C114ACD8 C114AD68 NIP [c01ffd2c] hid_suspend+0x1c/0x40 LR [c01d7a6c] usb_generic_suspend+0x88/0x98 Call trace: [c01d7a6c] usb_generic_suspend+0x88/0x98 [c018bb48] suspend_device+0x54/0x5c [c018bc24] device_suspend+0xd4/0x2ac [c04687c8] 0xc04687c8 [c0468cec] 0xc0468cec [c0469710] 0xc0469710 [c00772ac] do_ioctl+0x68/0x8c [c00774fc] vfs_ioctl+0x88/0x2a8 [c0077760] sys_ioctl+0x44/0x78 [c0004290] ret_from_syscall+0x0/0x4c - 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.6.11-rc3-mm1
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > On Fri, 2005-02-04 at 22:17 +0000, Sean Neakums wrote: >> I gave this a crack on the PowerBook5.4 -- somewhat more successful >> than 2.6.11-rc2-mm2. It boots, radeonfb works and X starts. However, >> suspend seems a tad faster than usual, and resume stops after setting >> the hard disk's DMA mode, although the log below made it to disk. > > Looks like USB is dying on wakeup... Anyway, that's still better than > 2.6.11 since your model will not sleep/wakeup at all without these > patches. > > I'll have to look into the USB thing. From the error messages, it looks > like at least some of my patches removing some old pmac IRQ cruft from > the ohci driver didn't make it (I though david picked it up a while ago > though). Or it could be a problem with the interrupt controller, I've > had reports of cases where the PIC just stops working on resume, I'm > still investigating. > > Is this totally reproduceable or does it wake up sometimes ? Have you > tried with USB disabled ? I tried it two or three times, same result each time. I'll give it a lash with USB disabled. - 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.6.11-rc3-mm1
I gave this a crack on the PowerBook5.4 -- somewhat more successful than 2.6.11-rc2-mm2. It boots, radeonfb works and X starts. However, suspend seems a tad faster than usual, and resume stops after setting the hard disk's DMA mode, although the log below made it to disk. eth0: suspending, WakeOnLan disabled orinoco_lock() called with hw_unavailable (dev=ef89d800) radeonfb (:00:10.0): suspending to state: 3... HID1, before: 8000fc80 radeonfb (:00:10.0): resuming from state: 3... PCI: Enabling device :00:10.0 ( -> 0003) HID1, after: 8000fc80 Apple USB OHCI 0001:10:18.0 disabled by firmware Apple USB OHCI 0001:10:19.0 disabled by firmware ehci_hcd 0001:10:1b.2: park 0 ehci_hcd 0001:10:1b.2: USB 2.0 restarted, EHCI 1.00, driver 10 Dec 2004 eth1: New link status: Connected (0001) eth0: resuming hda: Enabling Ultra DMA 5 Here's a resume log with 2.6.9 + sleep patch: eth0: suspending, WakeOnLan disabled radeonfb: suspending to state: 3... HID1, before: 8000fc80 radeonfb (:00:10.0): resuming from state: 0... PCI: Enabling device :00:10.0 ( -> 0003) HID1, after: 8000fc80 Apple USB OHCI 0001:10:18.0 disabled by firmware Apple USB OHCI 0001:10:19.0 disabled by firmware enable_irq(29) unbalanced enable_irq(63) unbalanced enable_irq(63) unbalanced eth0: resuming PHY ID: 1410cc1, addr: 0 hda: Enabling Ultra DMA 5 hdc: MDMA, cycleTime: 120, accessTime: 90, recTime: 30 hdc: Set MDMA timing for mode 2, reg: 0x00011d26 hdc: Enabling MultiWord DMA 2 hub 1-0:1.0: reactivate --> -22 hub 1-0:1.0: reactivate --> -22 hub 2-0:1.0: reactivate --> -22 - 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: Fw: Re: 2.6.11-rc2-mm2
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > On Sat, 2005-01-29 at 16:31 -0800, Andrew Morton wrote: >> help! >> >> Begin forwarded message: >> >> Date: Sat, 29 Jan 2005 23:56:23 + >> From: Sean Neakums <[EMAIL PROTECTED]> >> To: Andrew Morton <[EMAIL PROTECTED]> >> Cc: linux-kernel@vger.kernel.org >> Subject: Re: 2.6.11-rc2-mm2 >> >> >> Sean Neakums <[EMAIL PROTECTED]> writes: >> >> > On a PowerBook (PowerBook5.4), when snd_powermac is modprobed during >> > the boot, I get the following. After similar messages for a few more >> > modules, the machine seems wedged. >> >> Brice Goglin's patch fixes this. >> >> However, when I modprobe radeonfb I get: >> >> Jan 29 23:38:16 briny kernel: PCI: Unable to reserve mem region #1:[EMAIL >> PROTECTED] for device :00:10.0 >> Jan 29 23:38:16 briny kernel: radeonfb: probe of :00:10.0 failed with >> error -16 >> >> Not sure if this is expected or not on this platform. >> >> With radeonfb built-in (my current working configuration with 2.6.9) >> the screen clears and the machine seems to hang early in the boot. > > So, I did more tests. As I wrote previously, it's normal that radeonfb > as a module doesn't work when offb is in the kernel, we don't quite have > an infrastructure to deal with driver "replacement" yet. Not to worry. I only ended up with modular radeonfb when I was trying to narrow down the cause of the boot hang. [...] > radeonfb built-in operations seem to be ok on my PowerBook3,5 (ATI M9 > based), I'll try on a PowerBook5,4 (same as yours) tomorrow hopefully. > > Does the machine hang with the screen completely cleared ? Do you see > the penguin logo ? Did you try just using pmac_defconfig ? I seem some openpic messages and then the screen is cleared completely. Alas, I have the logo disabled in my configuration. I'll give pmac_defconfig a go this evening. I forgot to mention, after radeonfb failed to load as above, I fired up X. The display was unreadably corrupted, although the hardware cursor was fine and I could launch programs. Killing the X server did not return me to the console. I neglected to check if the machine was still accessible via the network. My current configuration (appended as oldconfig'd for 2.6.11-rc2-mm2) is the Debian one (2.6.8, flavour powerpc) with most of the =m changed to =y (for stuff I use) or else removed. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2-mm2 # Sat Jan 29 23:41:14 2005 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_LTT is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor # CONFIG_6xx=y # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set # CONFIG_8xx is not set # CONFIG_E500 is not set CONFIG_ALTIVEC=y CONFIG_TAU=y # CONFIG_TAU_INT is not set # CONFIG_TAU_AVERAGE is not set # CONFIG_KEXEC is not set CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_DEBUG is not set # CONFIG_CPU_FREQ_STAT is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_PMAC=y CONFIG_CPU_FREQ_TABLE=y CONFIG_PPC601_SYNC_FIX=y CONFIG_PM=y CONFIG_PPC_STD_MMU=y # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set # # Platform options # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_APUS is not set # CONFIG_KATANA is not set # CONFIG_WILLOW is not set # CONFIG_CPCI690 is not set # CONFIG_PCORE is not set # CONFIG_POWERPMC250 is not set # CONFIG_CHESTNUT is not set # CONFIG_SPRUCE is no
Re: 2.6.11-rc2-mm2
Sean Neakums <[EMAIL PROTECTED]> writes: > On a PowerBook (PowerBook5.4), when snd_powermac is modprobed during > the boot, I get the following. After similar messages for a few more > modules, the machine seems wedged. Brice Goglin's patch fixes this. However, when I modprobe radeonfb I get: Jan 29 23:38:16 briny kernel: PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :00:10.0 Jan 29 23:38:16 briny kernel: radeonfb: probe of :00:10.0 failed with error -16 Not sure if this is expected or not on this platform. With radeonfb built-in (my current working configuration with 2.6.9) the screen clears and the machine seems to hang early in the boot. - 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.6.11-rc2-mm2
On a PowerBook (PowerBook5.4), when snd_powermac is modprobed during the boot, I get the following. After similar messages for a few more modules, the machine seems wedged. Reversed bk-driver-core.patch and rebuilt, same result. kobject_register failed for snd_page_alloc (-17) Call Trace: dump_stack kobject_register mod_sysfs_setup load_module sys_init_module ret_from_syscall - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sunrpc: clarify the source of some messages
Sometimes cl_protname is "portmap", which can make it seem as if the
userspace portmapper is complaining, when in fact it is sunrpc that is
complaining. The second hunk also adds a missing printk level.
Against 2.6.11-rc1.
diff -urN --exclude '*~' S11-rc1/net/sunrpc/clnt.c
S11-rc1~sunrpc/net/sunrpc/clnt.c
--- S11-rc1/net/sunrpc/clnt.c 2005-01-15 11:45:16.0 +
+++ S11-rc1~sunrpc/net/sunrpc/clnt.c2005-01-15 16:15:10.0 +
@@ -631,7 +631,7 @@
}
if (encode && (status = rpcauth_wrap_req(task, encode, req, p,
task->tk_msg.rpc_argp)) < 0) {
- printk(KERN_WARNING "%s: can't encode arguments: %d\n",
+ printk(KERN_WARNING "RPC: %s: can't encode arguments: %d\n",
clnt->cl_protname, -status);
rpc_exit(task, status);
}
@@ -781,7 +781,7 @@
break;
default:
if (clnt->cl_chatty)
- printk("%s: RPC call returned error %d\n",
+ printk(KERN_NOTICE "RPC: %s: RPC call returned error
%d\n",
clnt->cl_protname, -status);
rpc_exit(task, status);
break;
@@ -806,7 +806,7 @@
dprintk("RPC: %4d call_timeout (major)\n", task->tk_pid);
if (RPC_IS_SOFT(task)) {
if (clnt->cl_chatty)
- printk(KERN_NOTICE "%s: server %s not responding, timed
out\n",
+ printk(KERN_NOTICE "RPC: %s: server %s not responding,
timed out\n",
clnt->cl_protname, clnt->cl_server);
rpc_exit(task, -EIO);
return;
@@ -814,7 +814,7 @@
if (clnt->cl_chatty && !(task->tk_flags & RPC_CALL_MAJORSEEN)) {
task->tk_flags |= RPC_CALL_MAJORSEEN;
- printk(KERN_NOTICE "%s: server %s not responding, still
trying\n",
+ printk(KERN_NOTICE "RPC: %s: server %s not responding, still
trying\n",
clnt->cl_protname, clnt->cl_server);
}
if (clnt->cl_autobind)
@@ -841,7 +841,7 @@
task->tk_pid, task->tk_status);
if (clnt->cl_chatty && (task->tk_flags & RPC_CALL_MAJORSEEN)) {
- printk(KERN_NOTICE "%s: server %s OK\n",
+ printk(KERN_NOTICE "RPC: %s: server %s OK\n",
clnt->cl_protname, clnt->cl_server);
task->tk_flags &= ~RPC_CALL_MAJORSEEN;
}
@@ -852,7 +852,7 @@
clnt->cl_stats->rpcretrans++;
goto out_retry;
}
- printk(KERN_WARNING "%s: too small RPC reply size (%d bytes)\n",
+ printk(KERN_WARNING "RPC: %s: too small RPC reply size (%d
bytes)\n",
clnt->cl_protname, task->tk_status);
rpc_exit(task, -EIO);
return;
-
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/
