Continue to get freezes on Chromebook PIxel
I continue to see freezes at random intervals on my Chromebook PIxel (2013). The X UI freezes completely for anywhere from a fraction of a second to several minutes but always eventually resumes. When it resumes there's normally nothing in dmesg or any other logs and no indication of exactly what exactly was happening when X was frozen. I had always chalked this up to the known problems with the intel graphics driver but apparently reports are that those problems are fixed and nobody else continues to see these freezes. I'm now suspecting that there's something else going on. Possibly the Sandisk iSSD apparently other Sandisk SSDs are buggy as hell so maybe the iSSD is as well? When the system returns there is usually a bunch of processes in disk wait including dm_crypt and usually several Chrome processes trying to page in stuff from swap. So blaming the SSD doesn't seem entirely out of line. On the other hand *anything* that locked up the PCI bus for a while would also cause lots of queued up I/O. I'm at a loss how to debug this. I'm looking for anything I can enable that would indicate what is blocking X and/or the kernel. Presumably there's some device driver waiting for some event for longer than is reasonable and either holding some kernel lock or hardware resource. Surely there are debug flags I can enable that will log whenever this happens so I can see after a freeze what was waiting on what for so long? I do have logs from a particularly long freeze where the kernel logged hung tasks. I suspect these just indicate what processes happened to be have wanted to do during the freeze that caused them to get stuck, not the culprit that actually caused them to get stuck. And I do have the intel driver debug flags enable but I think all this shows is that that the screensaver kicked in when the kernel finally unstuck and scheduled X: So please, if anyone has any suggestions of what tools to use or flags to enable to get visibility into what the kernel is doing when everything is frozen I would be more than happy to do further investigation on this end. Mar 26 17:06:52 pixel kernel: [174364.984072] INFO: task kworker/0:2:15108 blocked for more than 120 seconds. Mar 26 17:06:52 pixel kernel: [174364.984077] Tainted: G C 4.5.0-rc7-amd64 #1 Mar 26 17:06:52 pixel kernel: [174364.984078] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Mar 26 17:06:52 pixel kernel: [174364.984080] kworker/0:2 D 0 15108 2 0x Mar 26 17:06:52 pixel kernel: [174364.984088] Workqueue: events_freezable thermal_zone_device_check Mar 26 17:06:52 pixel kernel: [174364.984090] 8801000e0240 880060ab6f80 88012b494000 88012b493c50 Mar 26 17:06:52 pixel kernel: [174364.984092] 88014a8035c0 8801000e0240 88014a89bb80 a000e06d Mar 26 17:06:52 pixel kernel: [174364.984094] 815a81a1 7fff 815ab012 7fff Mar 26 17:06:52 pixel kernel: [174364.984096] Call Trace: Mar 26 17:06:52 pixel kernel: [174364.984102] [] ? schedule+0x31/0x80 Mar 26 17:06:52 pixel kernel: [174364.984104] [] ? schedule_timeout+0x1b2/0x270 Mar 26 17:06:52 pixel kernel: [174364.984108] [] ? acpi_ns_lookup+0x281/0x3a1 Mar 26 17:06:52 pixel kernel: [174364.984111] [] ? down_timeout+0x31/0x50 Mar 26 17:06:52 pixel kernel: [174364.984114] [] ? __down_timeout+0x75/0xc0 Mar 26 17:06:52 pixel kernel: [174364.984115] [] ? schedule_timeout+0x1a0/0x270 Mar 26 17:06:52 pixel kernel: [174364.984118] [] ? down_timeout+0x43/0x50 Mar 26 17:06:52 pixel kernel: [174364.984121] [] ? acpi_os_wait_semaphore+0x48/0x62 Mar 26 17:06:52 pixel kernel: [174364.984124] [] ? acpi_ut_acquire_mutex+0x44/0x7f Mar 26 17:06:52 pixel kernel: [174364.984126] [] ? acpi_ex_enter_interpreter+0xc/0x29 Mar 26 17:06:52 pixel kernel: [174364.984128] [] ? acpi_ns_evaluate+0x1b1/0x237 Mar 26 17:06:52 pixel kernel: [174364.984130] [] ? acpi_evaluate_object+0x13e/0x247 Mar 26 17:06:52 pixel kernel: [174364.984132] [] ? acpi_evaluate_integer+0x52/0x87 Mar 26 17:06:52 pixel kernel: [174364.984135] [] ? acpi_thermal_get_temperature+0x47/0x77 [thermal] Mar 26 17:06:52 pixel kernel: [174364.984137] [] ? thermal_get_temp+0x23/0x3a [thermal] Mar 26 17:06:52 pixel kernel: [174364.984139] [] ? thermal_zone_get_temp+0x4f/0x60 Mar 26 17:06:52 pixel kernel: [174364.984141] [] ? thermal_zone_device_update.part.22+0x28/0x160 Mar 26 17:06:52 pixel kernel: [174364.984144] [] ? process_one_work+0x15a/0x410 Mar 26 17:06:52 pixel kernel: [174364.984146] [] ? worker_thread+0x4d/0x480 Mar 26 17:06:52 pixel kernel: [174364.984148] [] ? process_one_work+0x410/0x410 Mar 26 17:06:52 pixel kernel: [174364.984151] [] ? kthread+0xcd/0xf0 Mar 26 17:06:52 pixel kernel: [174364.984153] [] ? kthread_create_on_node+0x190/0x190 Mar 26 17:06:52 pixel kernel: [174364.984156] [] ? ret_from_fork+0x3f/0x70 Mar 26 17:06:52 pixel kernel: [174364.984158] [] ?
Continue to get freezes on Chromebook PIxel
I continue to see freezes at random intervals on my Chromebook PIxel (2013). The X UI freezes completely for anywhere from a fraction of a second to several minutes but always eventually resumes. When it resumes there's normally nothing in dmesg or any other logs and no indication of exactly what exactly was happening when X was frozen. I had always chalked this up to the known problems with the intel graphics driver but apparently reports are that those problems are fixed and nobody else continues to see these freezes. I'm now suspecting that there's something else going on. Possibly the Sandisk iSSD apparently other Sandisk SSDs are buggy as hell so maybe the iSSD is as well? When the system returns there is usually a bunch of processes in disk wait including dm_crypt and usually several Chrome processes trying to page in stuff from swap. So blaming the SSD doesn't seem entirely out of line. On the other hand *anything* that locked up the PCI bus for a while would also cause lots of queued up I/O. I'm at a loss how to debug this. I'm looking for anything I can enable that would indicate what is blocking X and/or the kernel. Presumably there's some device driver waiting for some event for longer than is reasonable and either holding some kernel lock or hardware resource. Surely there are debug flags I can enable that will log whenever this happens so I can see after a freeze what was waiting on what for so long? I do have logs from a particularly long freeze where the kernel logged hung tasks. I suspect these just indicate what processes happened to be have wanted to do during the freeze that caused them to get stuck, not the culprit that actually caused them to get stuck. And I do have the intel driver debug flags enable but I think all this shows is that that the screensaver kicked in when the kernel finally unstuck and scheduled X: So please, if anyone has any suggestions of what tools to use or flags to enable to get visibility into what the kernel is doing when everything is frozen I would be more than happy to do further investigation on this end. Mar 26 17:06:52 pixel kernel: [174364.984072] INFO: task kworker/0:2:15108 blocked for more than 120 seconds. Mar 26 17:06:52 pixel kernel: [174364.984077] Tainted: G C 4.5.0-rc7-amd64 #1 Mar 26 17:06:52 pixel kernel: [174364.984078] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Mar 26 17:06:52 pixel kernel: [174364.984080] kworker/0:2 D 0 15108 2 0x Mar 26 17:06:52 pixel kernel: [174364.984088] Workqueue: events_freezable thermal_zone_device_check Mar 26 17:06:52 pixel kernel: [174364.984090] 8801000e0240 880060ab6f80 88012b494000 88012b493c50 Mar 26 17:06:52 pixel kernel: [174364.984092] 88014a8035c0 8801000e0240 88014a89bb80 a000e06d Mar 26 17:06:52 pixel kernel: [174364.984094] 815a81a1 7fff 815ab012 7fff Mar 26 17:06:52 pixel kernel: [174364.984096] Call Trace: Mar 26 17:06:52 pixel kernel: [174364.984102] [] ? schedule+0x31/0x80 Mar 26 17:06:52 pixel kernel: [174364.984104] [] ? schedule_timeout+0x1b2/0x270 Mar 26 17:06:52 pixel kernel: [174364.984108] [] ? acpi_ns_lookup+0x281/0x3a1 Mar 26 17:06:52 pixel kernel: [174364.984111] [] ? down_timeout+0x31/0x50 Mar 26 17:06:52 pixel kernel: [174364.984114] [] ? __down_timeout+0x75/0xc0 Mar 26 17:06:52 pixel kernel: [174364.984115] [] ? schedule_timeout+0x1a0/0x270 Mar 26 17:06:52 pixel kernel: [174364.984118] [] ? down_timeout+0x43/0x50 Mar 26 17:06:52 pixel kernel: [174364.984121] [] ? acpi_os_wait_semaphore+0x48/0x62 Mar 26 17:06:52 pixel kernel: [174364.984124] [] ? acpi_ut_acquire_mutex+0x44/0x7f Mar 26 17:06:52 pixel kernel: [174364.984126] [] ? acpi_ex_enter_interpreter+0xc/0x29 Mar 26 17:06:52 pixel kernel: [174364.984128] [] ? acpi_ns_evaluate+0x1b1/0x237 Mar 26 17:06:52 pixel kernel: [174364.984130] [] ? acpi_evaluate_object+0x13e/0x247 Mar 26 17:06:52 pixel kernel: [174364.984132] [] ? acpi_evaluate_integer+0x52/0x87 Mar 26 17:06:52 pixel kernel: [174364.984135] [] ? acpi_thermal_get_temperature+0x47/0x77 [thermal] Mar 26 17:06:52 pixel kernel: [174364.984137] [] ? thermal_get_temp+0x23/0x3a [thermal] Mar 26 17:06:52 pixel kernel: [174364.984139] [] ? thermal_zone_get_temp+0x4f/0x60 Mar 26 17:06:52 pixel kernel: [174364.984141] [] ? thermal_zone_device_update.part.22+0x28/0x160 Mar 26 17:06:52 pixel kernel: [174364.984144] [] ? process_one_work+0x15a/0x410 Mar 26 17:06:52 pixel kernel: [174364.984146] [] ? worker_thread+0x4d/0x480 Mar 26 17:06:52 pixel kernel: [174364.984148] [] ? process_one_work+0x410/0x410 Mar 26 17:06:52 pixel kernel: [174364.984151] [] ? kthread+0xcd/0xf0 Mar 26 17:06:52 pixel kernel: [174364.984153] [] ? kthread_create_on_node+0x190/0x190 Mar 26 17:06:52 pixel kernel: [174364.984156] [] ? ret_from_fork+0x3f/0x70 Mar 26 17:06:52 pixel kernel: [174364.984158] [] ?
Re: OSS Audio borked between 2.6.6 and 2.6.10
Andrew Morton <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> wrote: > > > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > Herbert tells me that this might be fixed in 2.6.11. Did you try that? > > > > Nope. I'll try that. > > Did it work? Oops, sorry I didn't get back. Yes. It works fine in 2.6.11.3 Thanks a lot for the help. -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Andrew Morton [EMAIL PROTECTED] writes: Greg Stark [EMAIL PROTECTED] wrote: Andrew Morton [EMAIL PROTECTED] writes: Herbert tells me that this might be fixed in 2.6.11. Did you try that? Nope. I'll try that. Did it work? Oops, sorry I didn't get back. Yes. It works fine in 2.6.11.3 Thanks a lot for the help. -- greg - 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 breaks modules gratuitously
When you guys go on these "make needlessly global code static" kicks you should maybe consider that even functions that aren't currently used by any other area of the tree might be useful for module writers. Instead of just checking which functions are currently used by other parts of the kernel perhaps you should think about what makes a logical API and stick to that, even if not all of the functions are currently used. In the case of net/core/datagram.c, why make skb_copy_datagram private but leave skb_copy_datagram_iovec global? If the latter is a useful public function why not the former? In particular vmware used skb_copy_datagram. So 2.6.11 broke vmware for no good reason. <[EMAIL PROTECTED]> [NET]: misc cleanups The patch below contains the following cleanups: - make needlessly global code static - remove the following unused global functions: - datagram.c: skb_copy_datagram - iovec.c: memcpy_tokerneliovec - remove the following unneeded EXPORT_SYMBOL's: - datagram.c: skb_copy_datagram - dev.c: ing_filter - iovec.c: memcpy_tokerneliovec - netpoll.c: netpoll_send_skb - rtnetlink.c: rtnetlink_dump_ifinfo - sock.c: sock_alloc_send_pskb Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> -- greg - 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 breaks modules gratuitously
When you guys go on these make needlessly global code static kicks you should maybe consider that even functions that aren't currently used by any other area of the tree might be useful for module writers. Instead of just checking which functions are currently used by other parts of the kernel perhaps you should think about what makes a logical API and stick to that, even if not all of the functions are currently used. In the case of net/core/datagram.c, why make skb_copy_datagram private but leave skb_copy_datagram_iovec global? If the latter is a useful public function why not the former? In particular vmware used skb_copy_datagram. So 2.6.11 broke vmware for no good reason. [EMAIL PROTECTED] [NET]: misc cleanups The patch below contains the following cleanups: - make needlessly global code static - remove the following unused global functions: - datagram.c: skb_copy_datagram - iovec.c: memcpy_tokerneliovec - remove the following unneeded EXPORT_SYMBOL's: - datagram.c: skb_copy_datagram - dev.c: ing_filter - iovec.c: memcpy_tokerneliovec - netpoll.c: netpoll_send_skb - rtnetlink.c: rtnetlink_dump_ifinfo - sock.c: sock_alloc_send_pskb Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] -- greg - 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: dmesg verbosity [was Re: AGP bogosities]
Linus Torvalds <[EMAIL PROTECTED]> writes: > And those occasional people are often not going to eb very good at > reporting bugs. If they don't see anything happening, they'll just give up > rather than bother to report it. So I do think we want the fairly verbose > thing enabled by default. You can then hide it with the graphical bootup > for "most people". Loading the usb drivers on my machine dumps 155 lines into dmesg. Surely that's a bit excessive? But really for me it's the network drivers that actually annoy me. They dump stuff into dmesg during the regular course of operation. As a result it doesn't take long until the boot messages leave the buffer. Of course they're in the log files, but running dmesg and getting screenfulls of the same messages about boring network events over and over just annoys me. -- greg - 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: dmesg verbosity [was Re: AGP bogosities]
Linus Torvalds [EMAIL PROTECTED] writes: And those occasional people are often not going to eb very good at reporting bugs. If they don't see anything happening, they'll just give up rather than bother to report it. So I do think we want the fairly verbose thing enabled by default. You can then hide it with the graphical bootup for most people. Loading the usb drivers on my machine dumps 155 lines into dmesg. Surely that's a bit excessive? But really for me it's the network drivers that actually annoy me. They dump stuff into dmesg during the regular course of operation. As a result it doesn't take long until the boot messages leave the buffer. Of course they're in the log files, but running dmesg and getting screenfulls of the same messages about boring network events over and over just annoys me. -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Andrew Morton <[EMAIL PROTECTED]> writes: > Herbert tells me that this might be fixed in 2.6.11. Did you try that? Nope. I'll try that. (Though I'm skeptical. It went from 2.6.6 to 2.6.10 without being noticed but now it's fixed without any reports?) -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
> Greg Stark <[EMAIL PROTECTED]> writes: > > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > Are you able to narrow it down to something more fine grained than > > > "between > > > 2.6.6 and 2.6.9-rc1"? > > > > Er, I suppose I would have to build some more kernels. Ugh. Is there a good > > place to start or do I have to just do a binary search? Well, I built a slew of kernels but found it on the first reboot. 2.6.7 doesn't work. I compiled the 2.6.6 drivers for 2.6.10 but they give ENODEV when I load them. > > 2.6.7: > > <[EMAIL PROTECTED]> > [PATCH] I2C: ICH6/6300ESB i2c support > > This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus). > In order to add this support I needed to patch pci_ids.h with the SMBus > DID's. To keep things orginized I renumbered the ICH6 and ESB entries > in pci_ids.h. I then patched the piix IDE and i810 audio drivers to > reflect the updated #define's. I also removed an error from irq.c; > there was a reference to a 6300ESB DID that does not exist. > > <[EMAIL PROTECTED]> > [sound/oss i810] pci id cleanups > > The driver defined its own PCI id constants. Kill the majority, > which were redundant, and move the rest to include/linux/pci_ids.h. > > Also, move open-coded tests for "new ICH" audio chips to a single > helper function. These tests were being patched with each new > ICH motherboard from Intel, resulting in each new PCI id being added > to several places in the driver. > > Note that, even though this should be a harmless patch, there > exists the remote possibility that I mis-matched some of the > PCI ids, as I only tested ICH5. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix wait queue race in drain_dac > > This particular one fixes a textbook race condition in drain_dac > that causes it to timeout when it shouldn't. > <[EMAIL PROTECTED]> > [sound/oss i810] fix race > > This patch fixes the value of swptr in case of an underrun/overrun. > > Overruns/underruns probably won't occur at all when the driver is > fixed properly, but this doesn't hurt. > > <[EMAIL PROTECTED]> > [sound/oss] remove bogus CIV_TO_LVI > > This patch removes a pair of bogus LVI assignments. The explanation in > the comment is wrong because the value of PCIB tells the hardware that > the DMA buffer can be processed even if LVI == CIV. > > Setting LVI to CIV + 1 causes overruns when with short writes > (something that vmware is very fond of). > > <[EMAIL PROTECTED]> > [sound/oss i810] clean up with macros > > This patch adds a number macros to clean up the code. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix partial DMA transfers > > This patch fixes a longstanding bug in this driver where partial > fragments > are fed to the hardware. Worse yet, those fragments are then extended > while the hardware is doing DMA transfers causing all sorts of problems. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix playback SETTRIGGER > > This patch fixes SETTRIGGER with playback so that the LVI is always > set and the DAC is always started. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix OSS fragments > > This patch makes userfragsize do what it's meant to do: do not start > DAC/ADC until a full fragment is available. > > <[EMAIL PROTECTED]> > [sound/oss i810] remove divides on playback > > This patch removes a couple of divides on the playback path. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix drain_dac loop when signals_allowed==0 > > This patch fixes another bug in the drain_dac wait loop when it is > called with signals_allowed == 0. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix reads/writes % 4 != 0 > > This patch removes another bogus chunk of code that breaks when > the application does a partial write. > > In particular, a read/write of x bytes where x % 4 != 0 will loop > forever. > > <[EMAIL PROTECTED]> > [sound/oss i810] fix deadlock in drain_dac > > This patch fixes a typo in a previous change that causes the driver > to deadlock under SMP. -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Greg Stark [EMAIL PROTECTED] writes: Andrew Morton [EMAIL PROTECTED] writes: Are you able to narrow it down to something more fine grained than between 2.6.6 and 2.6.9-rc1? Er, I suppose I would have to build some more kernels. Ugh. Is there a good place to start or do I have to just do a binary search? Well, I built a slew of kernels but found it on the first reboot. 2.6.7 doesn't work. I compiled the 2.6.6 drivers for 2.6.10 but they give ENODEV when I load them. 2.6.7: [EMAIL PROTECTED] [PATCH] I2C: ICH6/6300ESB i2c support This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus). In order to add this support I needed to patch pci_ids.h with the SMBus DID's. To keep things orginized I renumbered the ICH6 and ESB entries in pci_ids.h. I then patched the piix IDE and i810 audio drivers to reflect the updated #define's. I also removed an error from irq.c; there was a reference to a 6300ESB DID that does not exist. [EMAIL PROTECTED] [sound/oss i810] pci id cleanups The driver defined its own PCI id constants. Kill the majority, which were redundant, and move the rest to include/linux/pci_ids.h. Also, move open-coded tests for new ICH audio chips to a single helper function. These tests were being patched with each new ICH motherboard from Intel, resulting in each new PCI id being added to several places in the driver. Note that, even though this should be a harmless patch, there exists the remote possibility that I mis-matched some of the PCI ids, as I only tested ICH5. [EMAIL PROTECTED] [sound/oss i810] fix wait queue race in drain_dac This particular one fixes a textbook race condition in drain_dac that causes it to timeout when it shouldn't. [EMAIL PROTECTED] [sound/oss i810] fix race This patch fixes the value of swptr in case of an underrun/overrun. Overruns/underruns probably won't occur at all when the driver is fixed properly, but this doesn't hurt. [EMAIL PROTECTED] [sound/oss] remove bogus CIV_TO_LVI This patch removes a pair of bogus LVI assignments. The explanation in the comment is wrong because the value of PCIB tells the hardware that the DMA buffer can be processed even if LVI == CIV. Setting LVI to CIV + 1 causes overruns when with short writes (something that vmware is very fond of). [EMAIL PROTECTED] [sound/oss i810] clean up with macros This patch adds a number macros to clean up the code. [EMAIL PROTECTED] [sound/oss i810] fix partial DMA transfers This patch fixes a longstanding bug in this driver where partial fragments are fed to the hardware. Worse yet, those fragments are then extended while the hardware is doing DMA transfers causing all sorts of problems. [EMAIL PROTECTED] [sound/oss i810] fix playback SETTRIGGER This patch fixes SETTRIGGER with playback so that the LVI is always set and the DAC is always started. [EMAIL PROTECTED] [sound/oss i810] fix OSS fragments This patch makes userfragsize do what it's meant to do: do not start DAC/ADC until a full fragment is available. [EMAIL PROTECTED] [sound/oss i810] remove divides on playback This patch removes a couple of divides on the playback path. [EMAIL PROTECTED] [sound/oss i810] fix drain_dac loop when signals_allowed==0 This patch fixes another bug in the drain_dac wait loop when it is called with signals_allowed == 0. [EMAIL PROTECTED] [sound/oss i810] fix reads/writes % 4 != 0 This patch removes another bogus chunk of code that breaks when the application does a partial write. In particular, a read/write of x bytes where x % 4 != 0 will loop forever. [EMAIL PROTECTED] [sound/oss i810] fix deadlock in drain_dac This patch fixes a typo in a previous change that causes the driver to deadlock under SMP. -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Andrew Morton [EMAIL PROTECTED] writes: Herbert tells me that this might be fixed in 2.6.11. Did you try that? Nope. I'll try that. (Though I'm skeptical. It went from 2.6.6 to 2.6.10 without being noticed but now it's fixed without any reports?) -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Andrew Morton <[EMAIL PROTECTED]> writes: > The 2.6.6 i810_audio.c compiles OK in current kernels with the below patch > applied. This would be a good time to learn the right way to do this: how do I build a driver from a kernel tree without building the whole tree? Like, if I copy the 2.6.6 drivers to a new directory outside a kernel tree, is there some magic make command I can give it to point it at the 2.6.10 tree for the build environment including make includes and header files? -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Greg Stark <[EMAIL PROTECTED]> writes: > Andrew Morton <[EMAIL PROTECTED]> writes: > > > Are you able to narrow it down to something more fine grained than "between > > 2.6.6 and 2.6.9-rc1"? > > Er, I suppose I would have to build some more kernels. Ugh. Is there a good > place to start or do I have to just do a binary search? Oof. I just skimmed the Changelogs. It looks like the i810 OSS drivers got quite a rototilling in 2.6.7 and 2.6.8. It also kind of sounds like they needed it though. >From the look of this I doubt the 2.6.6 drivers will build or load into 2.6.10. 2.6.7: <[EMAIL PROTECTED]> [PATCH] I2C: ICH6/6300ESB i2c support This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus). In order to add this support I needed to patch pci_ids.h with the SMBus DID's. To keep things orginized I renumbered the ICH6 and ESB entries in pci_ids.h. I then patched the piix IDE and i810 audio drivers to reflect the updated #define's. I also removed an error from irq.c; there was a reference to a 6300ESB DID that does not exist. <[EMAIL PROTECTED]> [sound/oss i810] pci id cleanups The driver defined its own PCI id constants. Kill the majority, which were redundant, and move the rest to include/linux/pci_ids.h. Also, move open-coded tests for "new ICH" audio chips to a single helper function. These tests were being patched with each new ICH motherboard from Intel, resulting in each new PCI id being added to several places in the driver. Note that, even though this should be a harmless patch, there exists the remote possibility that I mis-matched some of the PCI ids, as I only tested ICH5. <[EMAIL PROTECTED]> [sound/oss i810] fix wait queue race in drain_dac This particular one fixes a textbook race condition in drain_dac that causes it to timeout when it shouldn't. <[EMAIL PROTECTED]> [sound/oss i810] fix race This patch fixes the value of swptr in case of an underrun/overrun. Overruns/underruns probably won't occur at all when the driver is fixed properly, but this doesn't hurt. <[EMAIL PROTECTED]> [sound/oss] remove bogus CIV_TO_LVI This patch removes a pair of bogus LVI assignments. The explanation in the comment is wrong because the value of PCIB tells the hardware that the DMA buffer can be processed even if LVI == CIV. Setting LVI to CIV + 1 causes overruns when with short writes (something that vmware is very fond of). <[EMAIL PROTECTED]> [sound/oss i810] clean up with macros This patch adds a number macros to clean up the code. <[EMAIL PROTECTED]> [sound/oss i810] fix partial DMA transfers This patch fixes a longstanding bug in this driver where partial fragments are fed to the hardware. Worse yet, those fragments are then extended while the hardware is doing DMA transfers causing all sorts of problems. <[EMAIL PROTECTED]> [sound/oss i810] fix playback SETTRIGGER This patch fixes SETTRIGGER with playback so that the LVI is always set and the DAC is always started. <[EMAIL PROTECTED]> [sound/oss i810] fix OSS fragments This patch makes userfragsize do what it's meant to do: do not start DAC/ADC until a full fragment is available. <[EMAIL PROTECTED]> [sound/oss i810] remove divides on playback This patch removes a couple of divides on the playback path. <[EMAIL PROTECTED]> [sound/oss i810] fix drain_dac loop when signals_allowed==0 This patch fixes another bug in the drain_dac wait loop when it is called with signals_allowed == 0. <[EMAIL PROTECTED]> [sound/oss i810] fix reads/writes % 4 != 0 This patch removes another bogus chunk of code that breaks when the application does a partial write. In particular, a read/write of x bytes where x % 4 != 0 will loop forever. <[EMAIL PROTECTED]> [sound/oss i810] fix deadlock in drain_dac This patch fixes a typo in a previous change that causes the driver to deadlock under SMP. 2.6.8: <[EMAIL PROTECTED]> [sound/oss i810] add MMIO DSP support Enclosed is a patch for the i810_audio OSS driver to support using memory-mapped I/O for those chipsets that support it. o Added a family of macros -- I810_IOREADx() and I810_IOWRITEx() -- that key off the existing card->use_mmio flag to select between using readx/writex or inx/outx f
Re: OSS Audio borked between 2.6.6 and 2.6.10
Andrew Morton <[EMAIL PROTECTED]> writes: > I would agree with that. If it's in the tree and the config system offers > it, it should work. And if it _used_ to work, and no longer does so then > double bad. Er, yeah, it's not like this is a new card that some crufty old driver never supported well. It worked fine in the past and got broke. > Are you able to narrow it down to something more fine grained than "between > 2.6.6 and 2.6.9-rc1"? Er, I suppose I would have to build some more kernels. Ugh. Is there a good place to start or do I have to just do a binary search? -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Alistair John Strachan <[EMAIL PROTECTED]> writes: > The intel8x0 driver is probably one of the most widely used ALSA drivers, so > I'd hope it wasn't broken! I would have hoped so too at the time. Reporting it to the list didn't get any response since it was already fixed upstream, but it took a while before it was merged down to the linux tree. Also, it seems chipsets can be wired up differently in different motherboards. A driver can work perfectly for hundreds of boards and still fail on the same chipset on another machine. In any case "X code is broken" "why not use Y code instead" isn't really productive. It's a good thing I was using the OSS drivers; if everyone used the alsa drivers and nobody was testing the OSS drivers nobody would know they were broken. -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Patrick McFarland <[EMAIL PROTECTED]> writes: > On Saturday 12 March 2005 01:31 pm, Greg Stark wrote: > > OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in > > 2.6.6. In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9 is > > affected as well. This is with the Intel i810 drivers. > > Why are you not using ALSA? Well frankly because whenever I tried it it didn't work. The i810 drivers were *completely* broken in the 2.6 kernel I original installed, 2.6.5 I think. In any case I understood that Quake doesn't work with alsa drivers because it depends on mmapped output which they don't support at all. Or something like that. I gave up on them when I found OSS worked reliably. Until someone broke it between 2.6.6 and 2.6.9. How likely are the 2.6.6 drivers to compile with 2.6.10? Is it worth trying? -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Patrick McFarland [EMAIL PROTECTED] writes: On Saturday 12 March 2005 01:31 pm, Greg Stark wrote: OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in 2.6.6. In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9 is affected as well. This is with the Intel i810 drivers. Why are you not using ALSA? Well frankly because whenever I tried it it didn't work. The i810 drivers were *completely* broken in the 2.6 kernel I original installed, 2.6.5 I think. In any case I understood that Quake doesn't work with alsa drivers because it depends on mmapped output which they don't support at all. Or something like that. I gave up on them when I found OSS worked reliably. Until someone broke it between 2.6.6 and 2.6.9. How likely are the 2.6.6 drivers to compile with 2.6.10? Is it worth trying? -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Alistair John Strachan [EMAIL PROTECTED] writes: The intel8x0 driver is probably one of the most widely used ALSA drivers, so I'd hope it wasn't broken! I would have hoped so too at the time. Reporting it to the list didn't get any response since it was already fixed upstream, but it took a while before it was merged down to the linux tree. Also, it seems chipsets can be wired up differently in different motherboards. A driver can work perfectly for hundreds of boards and still fail on the same chipset on another machine. In any case X code is broken why not use Y code instead isn't really productive. It's a good thing I was using the OSS drivers; if everyone used the alsa drivers and nobody was testing the OSS drivers nobody would know they were broken. -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Andrew Morton [EMAIL PROTECTED] writes: I would agree with that. If it's in the tree and the config system offers it, it should work. And if it _used_ to work, and no longer does so then double bad. Er, yeah, it's not like this is a new card that some crufty old driver never supported well. It worked fine in the past and got broke. Are you able to narrow it down to something more fine grained than between 2.6.6 and 2.6.9-rc1? Er, I suppose I would have to build some more kernels. Ugh. Is there a good place to start or do I have to just do a binary search? -- greg - 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: OSS Audio borked between 2.6.6 and 2.6.10
Greg Stark [EMAIL PROTECTED] writes: Andrew Morton [EMAIL PROTECTED] writes: Are you able to narrow it down to something more fine grained than between 2.6.6 and 2.6.9-rc1? Er, I suppose I would have to build some more kernels. Ugh. Is there a good place to start or do I have to just do a binary search? Oof. I just skimmed the Changelogs. It looks like the i810 OSS drivers got quite a rototilling in 2.6.7 and 2.6.8. It also kind of sounds like they needed it though. From the look of this I doubt the 2.6.6 drivers will build or load into 2.6.10. 2.6.7: [EMAIL PROTECTED] [PATCH] I2C: ICH6/6300ESB i2c support This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus). In order to add this support I needed to patch pci_ids.h with the SMBus DID's. To keep things orginized I renumbered the ICH6 and ESB entries in pci_ids.h. I then patched the piix IDE and i810 audio drivers to reflect the updated #define's. I also removed an error from irq.c; there was a reference to a 6300ESB DID that does not exist. [EMAIL PROTECTED] [sound/oss i810] pci id cleanups The driver defined its own PCI id constants. Kill the majority, which were redundant, and move the rest to include/linux/pci_ids.h. Also, move open-coded tests for new ICH audio chips to a single helper function. These tests were being patched with each new ICH motherboard from Intel, resulting in each new PCI id being added to several places in the driver. Note that, even though this should be a harmless patch, there exists the remote possibility that I mis-matched some of the PCI ids, as I only tested ICH5. [EMAIL PROTECTED] [sound/oss i810] fix wait queue race in drain_dac This particular one fixes a textbook race condition in drain_dac that causes it to timeout when it shouldn't. [EMAIL PROTECTED] [sound/oss i810] fix race This patch fixes the value of swptr in case of an underrun/overrun. Overruns/underruns probably won't occur at all when the driver is fixed properly, but this doesn't hurt. [EMAIL PROTECTED] [sound/oss] remove bogus CIV_TO_LVI This patch removes a pair of bogus LVI assignments. The explanation in the comment is wrong because the value of PCIB tells the hardware that the DMA buffer can be processed even if LVI == CIV. Setting LVI to CIV + 1 causes overruns when with short writes (something that vmware is very fond of). [EMAIL PROTECTED] [sound/oss i810] clean up with macros This patch adds a number macros to clean up the code. [EMAIL PROTECTED] [sound/oss i810] fix partial DMA transfers This patch fixes a longstanding bug in this driver where partial fragments are fed to the hardware. Worse yet, those fragments are then extended while the hardware is doing DMA transfers causing all sorts of problems. [EMAIL PROTECTED] [sound/oss i810] fix playback SETTRIGGER This patch fixes SETTRIGGER with playback so that the LVI is always set and the DAC is always started. [EMAIL PROTECTED] [sound/oss i810] fix OSS fragments This patch makes userfragsize do what it's meant to do: do not start DAC/ADC until a full fragment is available. [EMAIL PROTECTED] [sound/oss i810] remove divides on playback This patch removes a couple of divides on the playback path. [EMAIL PROTECTED] [sound/oss i810] fix drain_dac loop when signals_allowed==0 This patch fixes another bug in the drain_dac wait loop when it is called with signals_allowed == 0. [EMAIL PROTECTED] [sound/oss i810] fix reads/writes % 4 != 0 This patch removes another bogus chunk of code that breaks when the application does a partial write. In particular, a read/write of x bytes where x % 4 != 0 will loop forever. [EMAIL PROTECTED] [sound/oss i810] fix deadlock in drain_dac This patch fixes a typo in a previous change that causes the driver to deadlock under SMP. 2.6.8: [EMAIL PROTECTED] [sound/oss i810] add MMIO DSP support Enclosed is a patch for the i810_audio OSS driver to support using memory-mapped I/O for those chipsets that support it. o Added a family of macros -- I810_IOREADx() and I810_IOWRITEx() -- that key off the existing card-use_mmio flag to select between using readx/writex or inx/outx for I/O operations. o Converted existing inx/outx invocations to use I810_IOREADx/I810_IOWRITEx instead. o Changed GET_CIV(), GET_LVI, and CIV_TO_LVI
Re: OSS Audio borked between 2.6.6 and 2.6.10
Andrew Morton [EMAIL PROTECTED] writes: The 2.6.6 i810_audio.c compiles OK in current kernels with the below patch applied. This would be a good time to learn the right way to do this: how do I build a driver from a kernel tree without building the whole tree? Like, if I copy the 2.6.6 drivers to a new directory outside a kernel tree, is there some magic make command I can give it to point it at the 2.6.10 tree for the build environment including make includes and header files? -- greg - 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/
OSS Audio borked between 2.6.6 and 2.6.10
OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in 2.6.6. In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9 is affected as well. This is with the Intel i810 drivers. Quake3 just prints "dropping sound" over and over again and doesn't output any sound in the actual game (the menus seem to work 50% of the time). I assume this is related to Quake3's use of the memory mapped audio interface. Perhaps it's never getting interrupts through the ioctl interface? Here is the lspci info: :00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OSS Audio borked between 2.6.6 and 2.6.10
OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in 2.6.6.
In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9 is affected as
well. This is with the Intel i810 drivers.
Quake3 just prints dropping sound over and over again and doesn't output any
sound in the actual game (the menus seem to work 50% of the time). I assume
this is related to Quake3's use of the memory mapped audio interface. Perhaps
it's never getting interrupts through the ioctl interface?
Here is the lspci info:
:00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R)
AC'97 Audio Controller (rev 02)
Subsystem: Asustek Computer, Inc. P4P800 Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0
Interrupt: pin B routed to IRQ 17
Region 0: I/O ports at e800 [size=256]
Region 1: I/O ports at ee80 [size=64]
Region 2: Memory at f7fff400 (32-bit, non-prefetchable) [size=512]
Region 3: Memory at f7fff000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
I tried it with pci=routeirq but no change.
The strace from quake running on the two kernels looks essentially identical.
Here are all the syscalls that look relevant from the 2.6.10. The output is
essentially identical for 2.6.6 except for the memory addresses, pid, and the
number of omitted read calls where the ellipses are. Note, that it *does*
print sound system is muted in 2.6.6 as well, but it works fine.
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xb718) = -1 ENOTTY (Inappropriate
ioctl for device)
[pid 8904] write(2, \n--- sound initialization --..., 38
--- sound initialization ---
[pid 8904] open(/dev/dsp, O_RDWR)= 19
[pid 8904] ioctl(19, SNDCTL_DSP_GETCAPS, 0xb774) = 0
[pid 8904] ioctl(19, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0x81776ac) = 0
[pid 8904] ioctl(19, SNDCTL_DSP_STEREO, 0xb76c) = 0
[pid 8904] ioctl(19, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0x88446b4) = 0
[pid 8904] ioctl(19, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, 0xb768) = 0
[pid 8904] ioctl(19, SNDCTL_DSP_GETOSPACE, 0xb780) = 0
[pid 8904] ioctl(19, SNDCTL_DSP_GETTRIGGER, 0xb76c) = 0
[pid 8904] ioctl(19, SNDCTL_DSP_GETTRIGGER, 0xb76c) = 0
[pid 8904] write(2, sound system is muted\n, 22sound system is muted
[pid 8904] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
[pid 8904] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
[pid 8904] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
[pid 8904] ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon
-echo ...}) = 0
[pid 8904] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon
-echo ...}) = 0
[pid 8904] fcntl64(0, F_GETFL) = 0x2 (flags O_RDWR)
[pid 8904] fcntl64(0, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xbffef0cf, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xbffef264) = 0
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xb5af, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xb744) = 0
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xb5af, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xb744) = 0
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
...
[pid 8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xb744) = 0
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
...
[pid 8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xb744) = 0
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xbfffb62f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 8904] read(0, 0xbfffdfcb, 1)
Re: [PATCH] scsi/sata write barrier support
Jens Axboe <[EMAIL PROTECTED]> writes: > > What about a non-journaled fs, or at least a meta-data-only-journaled fs? > > Journaled FS's don't mix well with transaction based databases since they're > > basically doing their own journaling anyways. > > Only works on ext3 and reiserfs currently. Does it work in resierfs with data=writeback or ext3 with tune2fs's journal_data_writeback? What I'm wondering is whether it only kicks in when the journal gets synchronized or whether it kicks in whenever you call fsync even if no journaling is involved. Writeback mode isn't really necessary, Postgres makes every effort to use fdatasync or equivalent so no metadata changes are really necessary. So the question is also, do the filesystems initiate a cache flush even if no metadata changes are being synchronized? -- greg - 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] scsi/sata write barrier support
Jens Axboe [EMAIL PROTECTED] writes: What about a non-journaled fs, or at least a meta-data-only-journaled fs? Journaled FS's don't mix well with transaction based databases since they're basically doing their own journaling anyways. Only works on ext3 and reiserfs currently. Does it work in resierfs with data=writeback or ext3 with tune2fs's journal_data_writeback? What I'm wondering is whether it only kicks in when the journal gets synchronized or whether it kicks in whenever you call fsync even if no journaling is involved. Writeback mode isn't really necessary, Postgres makes every effort to use fdatasync or equivalent so no metadata changes are really necessary. So the question is also, do the filesystems initiate a cache flush even if no metadata changes are being synchronized? -- greg - 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] scsi/sata write barrier support
Jens Axboe <[EMAIL PROTECTED]> writes: > fsync has been working all along, since the initial barrier support for > ide. only ext3 and reiserfs support it. Really? That's huge news. Since what kernel version(s) is that? What about a non-journaled fs, or at least a meta-data-only-journaled fs? Journaled FS's don't mix well with transaction based databases since they're basically doing their own journaling anyways. -- greg - 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] scsi/sata write barrier support
Jens Axboe [EMAIL PROTECTED] writes: fsync has been working all along, since the initial barrier support for ide. only ext3 and reiserfs support it. Really? That's huge news. Since what kernel version(s) is that? What about a non-journaled fs, or at least a meta-data-only-journaled fs? Journaled FS's don't mix well with transaction based databases since they're basically doing their own journaling anyways. -- greg - 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: the umount() saga for regular linux desktop users
William <[EMAIL PROTECTED]> writes: > In my opinion, in order for linux to be trully user friendly, "a umount() > should NEVER fail" (even if the device containing the filesystem is no > longuer attached to the system). The kernel should do it's best to satisfy > the umount request and cleanup. Maybe the kernel could try some of the > following: What you're asking for is for the umount -f option to be supported. This isn't a new fangled idea. BSD supported has supported it since sometime in the last millennium. Seriously, it's pretty basic functionality and really ought to be supported. The semantics of umount -f are simpler than you make it sound. It just unmounts the file system normally and revokes any file descriptors for that file system. Any further i/o on those file descriptors just gets an error (EINVAL I expect). This is one of my biggest pet peeves about Linux. -- greg - 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: the umount() saga for regular linux desktop users
William [EMAIL PROTECTED] writes: In my opinion, in order for linux to be trully user friendly, a umount() should NEVER fail (even if the device containing the filesystem is no longuer attached to the system). The kernel should do it's best to satisfy the umount request and cleanup. Maybe the kernel could try some of the following: What you're asking for is for the umount -f option to be supported. This isn't a new fangled idea. BSD supported has supported it since sometime in the last millennium. Seriously, it's pretty basic functionality and really ought to be supported. The semantics of umount -f are simpler than you make it sound. It just unmounts the file system normally and revokes any file descriptors for that file system. Any further i/o on those file descriptors just gets an error (EINVAL I expect). This is one of my biggest pet peeves about Linux. -- greg - 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/
