[REGRESSION] -rc7/-rc4+: unable to USB boot - enumeration partially broken (was: Linux v3.8-rc7)
Hi, I hate having to report a suspected regression this late in the cycle again (last time it turned out to be a false alarm due to .config issue, ouch)... In the previous life of this Aspire One machine (prior to a grave reboot sync issue corrupting my system unrecoverably, i.e. only 3 hours reinstall for *full* config, minor loss fortunately) I had a working 3.7.0 kernel. After the reinstall I tried to get a current -rc (-rc4+) working. To my surprise initramfs USB boot failed, completely. (the tell-tale sign that it likely is a regression was that the same 3.7.0 kernel that had been working previously, built via make oldconfig of the **-rc** .config and with identical commands as -rc - using make install - was then again found to be booting fine!) The initramfs symptoms were that (in initramfs rescue shell) /dev/disk/by-uuid/ failed to contain the entry for my USB boot SSD. Turned out that cat /sys/bus/usb/devices/*/product failed to list several of my devices. What's worse, hotplug of any additional devices (USB stick, USBHID gamepad) ought to have managed to successfully show up, due to the udev setup of my initrd. On a successful boot (to desktop), I have: # lsusb -tv /: 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 /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 2: Dev 2, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 2: Dev 2, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 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 2, If 0, Class=stor., Driver=usb-storage, 480M |__ Port 5: Dev 4, If 0, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M |__ Port 5: Dev 4, If 1, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M # lsusb 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 Bus 001 Device 002: ID 152d:0601 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 001 Device 004: ID 064e:d101 Suyin Corp. Acer CrystalEye Webcam Bus 003 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Removing "quiet" boot parm and adding "debug", I noticed that a working kernel (default 3.2.0 package) properly discovered all USB devices, thus was able to continue with root filesystem activation. Newer -rc (tested 3.8-rc4+, 3.8-rc7) got stuck on the line of discovery of the BT2.0 device ID, with both JMicron and Suyin camera not getting discovered. However, this observed behaviour should perhaps more correctly be interpreted as enumeration *ending* at Bus 003 rather than the kernel getting stuck there, and thus *only* Bus 001 simply *not* having gotten enumerated (perhaps due to newly introduced BIOS handoff issues of the *active BIOS boot device* at this bus???). OTOH only some of my external ports are Bus 001 (some are 003), thus if only Bus 001 was unavailable, devices should have shown up when plugging into 003. I think I did try all ports, but unsure, will have to retest shortly (this is important to distinguish Port 001 suspected handoff issue vs. all-busses-stuck issue). I've even gone to the pain of using scripts/diffconfig, without fruitful results (hrmm, now I remember that I did change CONFIG_CONNECTOR from m to y - there's a tiny chance that this might have fixed it, but then the faxt that it discovered *one* device - BT2.0 - should of course then have successfully followed through with discovering all others, too). So, did anyone observe similar behaviour in USB enumeration (known issues?), or any hints/ideas about changes to blame [USB handoff?], or anything that's missing here? I might choose to go the bisection route :( Experiencing too many grave issues even with recent kernels somehow (which obviously leads me to rather liking the more recent strictly-fixes-only policy). Thanks, Andreas Mohr -- 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] -rc7/-rc4+: unable to USB boot - enumeration partially broken (was: Linux v3.8-rc7)
Hi, On Sun, Feb 10, 2013 at 01:14:42AM +0100, Andreas Mohr wrote: > After the reinstall I tried to get a current -rc (-rc4+) working. > To my surprise initramfs USB boot failed, completely. > (the tell-tale sign that it likely is a regression was that the same 3.7.0 > kernel that had been working previously, built via make oldconfig of > the **-rc** .config and with identical commands as -rc - using make install - > was then again found to be booting fine!) Regression sorta confirmed now. -rc3 with a fully suitable .config does not boot either. Will start bisection. Will take ages. Andreas Mohr -- 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] -rc7/-rc4+: unable to USB boot - enumeration partially broken (was: Linux v3.8-rc7)
On Sun, Feb 10, 2013 at 03:05:54PM +0100, Andreas Mohr wrote: > Regression sorta confirmed now. -rc3 with a fully suitable .config does > not boot either. Will start bisection. Will take ages. Down to 91 commits (all in USB land!), around 7 steps left. Pretty certain of a valid regression now. Things did properly do the good/good/bad/bad/good... dance. Oh so lovely if you're constrained to >= 5 hour build times, with almost every bisection step doing reduction of the config set in larger areas, to try to finally hit <= 2 hours... (7 steps --> ~ one day) Andreas Mohr -- 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] -rc7/-rc4+: unable to USB boot - enumeration partially broken (was: Linux v3.8-rc7)
Hi, On Tue, Feb 12, 2013 at 08:16:17AM -0800, Greg KH wrote: > On Tue, Feb 12, 2013 at 05:07:27PM +0100, Andreas Mohr wrote: > > On Sun, Feb 10, 2013 at 03:05:54PM +0100, Andreas Mohr wrote: > > > Regression sorta confirmed now. -rc3 with a fully suitable .config does > > > not boot either. Will start bisection. Will take ages. > > > > Down to 91 commits (all in USB land!), around 7 steps left. > > Pretty certain of a valid regression now. Things did properly do the > > good/good/bad/bad/good... dance. > > > > Oh so lovely if you're constrained to >= 5 hour build times, > > You do know about 'make localmodconfig', right? That should cut your > build time down a large amount. No, I didn't know, and quirky kernel docs don't know either (yet another item I've got to add to my update commits) [and 1.7.10.4 bisect man obviously doesn't mention it either]. Hrmm, README does explain it. Ought to have managed to read at least the first batch of rough introductory docs parts in full, mayhaps? :% Still, something to be referenced in a (currently very terse) more suitable doc for bisection (i.e. BUG-HUNTING). Thanks two tons for the life-saver! :) Current candidates remaining (45 revisions, 6 steps, git bisect visualize --oneline), for those who might already want to know it at this moment (and yes, the last one was bad, so seems I'm on track): 09f6ffd USB: EHCI: fix build error by making ChipIdea host a normal EHCI driver 5746510 USB: ohci-exynos: initialize registers pointer earlier d1bb67a USB: EHCI: fix build error in ehci-platform.c under PowerPC 99f9193 USB: EHCI: make ehci-platform a separate driver adfa79d USB: EHCI: make ehci-pci a separate driver 3e02320 USB: EHCI: prepare to make ehci-hcd a library module 7c83b44 USB: option: idVendor and idProduct are __le16 dbdf680 USB: option: replace vendor probe rule with match flags 17b72fe USB: add USB_DEVICE_INTERFACE_CLASS macro 1b95bee USB: option: never bind to a usb-storage interface c73cee7 USB: EHCI: remove ehci_port_power() routine 4968f95 USB: EHCI: remove unused Link Power Management code 571e412 USB: remove iteration limit in hub_tt_work() bcbec05 USB: serial: remove driver version information 806df3a USB: ums_realtek: fix build warning 5fb0432 USB: ftdi_sio: use ftdi_get_modem_status in chars_in_buffer 8da636d USB: ftdi_sio: optimise chars_in_buffer 755b604 USB: ftdi_sio: use generic chars_in_buffer 428d998 USB: serial: export usb_serial_generic_chars_in_buffer a4afff6 USB: ftdi_sio: refactor modem-control status retrieval 2c2ee54 USB: ftdi_sio: fix tiocmget and tiocmset return values fef0b82 USB: ftdi_sio: fix tiocmget indentation 81e8442 USB: ftdi_sio: remove unused private port-data 86effe5 USB: fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT di d067a31 USB: ftdi_sio: remove unnecessary memset 4f2ab88 USB: cp210x: fix whitespace issues 487c151 USB: iuu_phoenix: replace strict_strtoul() with kstrtoul() f2ec522 usb: Convert dev_printk(KERN_ to dev_( b472b8e Merge 3.7-rc3 into usb-next. d124a60 USB: isp1760-if: Change to use irq_of_parse_and_map 596d789 USB: set hub's default autosuspend delay as 0 e6f30de USB: check port changes before hub runtime suspend for some bug device b717727 umc-bus.c: fix usage of device_trylock 6f60291 usb: serial: ftdi_sio: Add missing chars_in_buffer function bd066ee usb: "ehci-w90x900" Fix a typo and add some whitespace. bfd1e91 USB: speed up usb_bus_resume() 969ddcf USB: hub_for_each_child should skip unconnected ports d39dbc8 USB: EHCI: move ehci_update_device() to ehci-lpm.c acc0850 USB: EHCI: make ehci_read_frame_index platform independent d6064ac USB: EHCI: move logging macros to ehci.h 6273f18 USB: EHCI: add condition for delay during the resume e8cebb9 USB: usb-skeleton.c: fix compilation error and restored kref_put on fail 801f006 USB: ohci-s3c2410: use devm_ functions 30b1e49 USB: use bus_to_hdc instead of container_of 60d80ad USB: ohci-exynos: use devm_clk_get() c05c946 usb: ohci-exynos: use clk_prepare_enable and clk_disable_unprepare e1deb56 usb: ehci-s5p: use clk_prepare_enable and clk_disable_unprepare ffc7493 usb: phy: tegra remove include of 54388b2 usb: host: tegra remove include of c30186e USB: ezusb: unexport some functions that aren't being used 068b054 USB: OHCI: sm501: fix build failure after ohci_finish_controller_resume 5843de3 MIPS: Alchemy: update development boards defconfigs with USB platform dr da31fe4 WUSB: remove an unnused variable be7ac70 USB: OHCI: make ohci-platform use devm_request_and_ioremap helper 61ff274 USB: EHCI: make ehci-platform use devm_request_and_ioremap helper ac0e3c0 USB: OHCI: fix typo in ohci-platform driver on the word "resource" 5c9b2b2 USB: EHCI: fix typo in ehci-platform driver on the word "resource" 976baf6 USB: OHCI: make ohci-platform use dev_err() instead of pr_err() 2350cb0 US
Re: [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE
Hi, first, thanks a lot for advancing PM infrastructure! > #define PM_SUSPEND_ON((__force suspend_state_t) 0) > -#define PM_SUSPEND_STANDBY ((__force suspend_state_t) 1) > +#define PM_SUSPEND_FREEZE((__force suspend_state_t) 1) > +#define PM_SUSPEND_STANDBY ((__force suspend_state_t) 2) > #define PM_SUSPEND_MEM ((__force suspend_state_t) 3) > +#define PM_SUSPEND_MIN PM_SUSPEND_FREEZE > #define PM_SUSPEND_MAX ((__force suspend_state_t) 4) I'll just pretend to be hopeful that you managed to hunt down all relevant code sites (possibly even splattered around drivers?) which may have made illegally hard-coded assumptions about the number of PM_SUSPEND state "enum"s ;) (e.g. comparisons - such as "==", "<=" etc. - come into mind) Review of your patch was all fine, nothing to object about. Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block/partition/msdos: detect AIX formatted disks even without 55aa
Hi,
IMHO that patch would better have a small but important one-liner comment
(one cannot rely on people always making use of SCM history functionality,
thereby this would be at risk of getting reversed accidentally eventually).
E.g.
/* Note order! (some AIX disks, e.g. unbootable kind, have no MSDOS 55aa) */
if (aix_magic_present(state, data)) {
.
.
.
Apart from that: nice compat catch!
HTH,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
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/
usb storage: FATAL DATA CORRUPTION due to innocuous reboot!?
Hi, after my recent tirade of very poor device support of Aspire One, I now experienced something a lot worse (bad karma? ;-P): basically my entire ext4 root partition got blewn into shreds (corruption is so pervasive that I'm afraid recovery will fail). I am (was) running 3.7.0, and decided to upgrade to current (-rc4+). Thus I did grub-mkconfig and more or less immediately rebooted. Realized that I had failed to copy vmlinuz to /boot's bzImage (i.e. new boot entry was missing), rebooted and redid that, re-ran grub-mkconfig and rebooted more or less immediately. After the first grub-mkconfig GRUB2 was still fine, being able to boot the existing kernel. Exactly directly after the second reboot (post-grub-mkconfig) all hell broke lose, with GRUB2 complaining about "invalid extent" and a subsequent fsck.ext4 spewing tons of pages of errors. I'm using the infamous JMF601 SSD controller, USB-connected (root device). Cannot provide details of grub package version since root partition is toast. Note that the first inode that fsck complained about was 262144, i.e. 0x4 i.e. 256kB i.e. most certainly directly at a boundary of erase block size. IOW, the corruption is very likely to have been produced by coarse erase block related activity and *not* by any interim merging of *partial* data updates. While of course the corruption may have happened due to a questionable device, I now have a hunch that this unspeakable mess has been caused by the reboot happening too early (while the SSD was still writing data, probably by having to actively and painfully erase formerly used blocks, too). If the reboot happened too early, this would probably mean that USB port power during reboot got lost too early, thus the controller lost power during ongoing data updates. If the controller's operation happens to be implemented in a not fully atomic way (as is somewhat likely given JMF601's reputation), then this means data corruption, plenty. Thus I started to investigate about the kernel's device consistency guarantees upon reboot. Note that reboot(8) says: " The -h flag puts all hard disks in standby mode just before halt or power-off. Right now this is only implemented for IDE drives. A side effect of putting the drive in stand-by mode is that the write cache on the disk is flushed. This is important for IDE drives, since the kernel doesn't flush the write cache itself before power-off. " Excuse me!? Why wouldn't the kernel be responsible to take care to flush things prior to power-off? Also, http://linux.die.net/man/8/sync (a possibly old/irrelevant source) says: "The reboot(8) and halt(8) commands take this into account by sleeping for a few seconds after calling sync(2)" Please forgive me for a second that I'm *very* puzzled why it would be the reboot binary's job to do a delay to ensure properly completed syncing/flushing of the storage devices. After all it's quite arguably definitely the *kernel*'s job to govern device-specific flush delay requirements (only the kernel knows which particular device may have certain particularly special manual delay requirements, and all that a userspace binary ought to do is to issue a *client request* for a reboot). Please note that the sync binary is only about syncing filesystem-related parts, i.e. it does NOT seem to be responsible for the (much more important!!) non-fs parts such as the things updated by GRUB (is this the hole that I'm seeing here?). So, to have a short list: - I suspect improper sync/flush handling prior to reboot (which likely eventually leads to the obviously fatal USB port poweroff) - it's possibly the case that sync handling is sufficient to handle FS parts but not the even more critical non-FS parts (bootloader) - kernel might actually do a proper sync/flush of *all* device parts, but device may fail to obey it If it in fact is a problem specific to this device, then it might be conceivable to introduce a new USB storage quirk flag for devices with broken flush which would add an arbitrary pre-reboot delay of perhaps 10 seconds. If the kernel has a last-write-at timestamp per block device (which it arguably should maintain), then this could be used to shorten the delay to the time remaining since last write (which also would allow to prolong the total delay to 20 seconds). Questions: - should I file a kernel bug report about this issue? - did anyone experience anything similar? (research didn't manage to locate much so far) - if my thoughts are correct (about storage quirk), how to implement it? - any other hints/ideas? I have to admit that all these way too many kernel "features" are really adding up going on my nerves (Alan Cox, anyone?). If this keeps going on, then I *will* be forced to bail out, hard. Thanks, Andreas Mohr -- To unsubscribe from this list: send the
Re: [PATCH 0/3] Include kernel config by default
Hi, [CC'd extract-ikconfig creator] > I've seen too many systems where the config to build the used kernel got > lost and people were unable to diagnose problems or to rebuild a modified > or updated kernel. It's a subject which worries me since several years. I'm strongly in favour of such a change. The actual config is simply very important for traceability. In a recent case of mine I simply built the kernel on an external HDD and did not copy the config file on deployment (e.g. to /boot). With that kernel build tree then unavailable, I then realized that this kernel fortunately did have IKCONFIG_PROC enabled, thus configs.ko was available for (re-)use. However an argument could be made that the default setting should be the bare-minimum needed to provide this information source in emergency cases (i.e., a manual run of scripts/extract-ikconfig would be in order and easily acceptable). $ ls -l kernel/configs.ko -rw-r--r-- 1 root root 35788 Jan 25 18:43 kernel/configs.ko IMHO more than 32kB for the proc/config.gz module arguably is quite a bit of code for it to painlessly be enabled by default given availability of other methods of retrieval. However, now that I think of it ISTR that using extract-ikconfig on my bzImage did NOT work yet loading configs.ko of the same install successfully provided a /proc/config.gz. Huh?? If this is the case, then one or both of these things ought to be done: - make extract-ikconfig not fail in such a case - [failing the prior one] enable /proc/config.gz by default, too Aww wait: I was mistaken in thinking that the config data is statically included in the kernel and configs.ko then is about providing /proc only. This not being the case (config data itself is provided by *module*, too) explains both my extract-ikconfig failure on the static kernel image and the size of configs.ko, so additionally enabling /proc/config.gz in this module most likely is a non-issue. However, this means that extract-ikconfig is missing a user error message indicating that the reason for lookup failure perhaps is that the setting is module-based and thus cannot be found in image (extract-ikconfig's header comments don't fully document this fact either). Will be creating a commit for this eventually (or do you want to add such thing to your patchset now? ;). Thanks for your effort, Andreas Mohr -- 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: weird keyboard issue (ps/2 port?) 3.9.x/3.10.x?
Hi, > What could this be? > Is it really a software issue? > If so: how could I help fix this? Perhaps watching the output of some input event tools could help gather some clues to eventually get it nailed down? Some candidates: evtest - utility to monitor Linux input device events input-utils - utilities for the input layer of the Linux kernel xinput - Runtime configuration and test of XInput devices And what do /proc/interrupts counts say? Does PS/2 (i8042) generate events? while :; do clear; cat /proc/interrupts; sleep 1; done HTH [shot in the dark], Andreas Mohr -- 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: 3.11-rc6 many problems, wil6210 , snd-pcsp , ibmphp
Hi, > / The snd-pcsp module don't work.It don't load even > with option snd-pcsp index=1 , it gives a message that the > device is > ocupied. Typing in beep , it's beeping, so I suppose > my computer has a beeper. Perhaps any default speaker > module occupies > the speaker ? It should be programmed correctly in the > pcsp module, that loading it it desocupy the speaker. >The beeper > programming specialist should check this module, I tried > it for several kernel versions and computers, it never > works. Have to provide a "me too". Was interested in it when it first appeared in kernel in semi-recentish times, did not get it to work other than producing some random clicking. I'm very sad to say that the High-Fidelity-Enhanced speaker driver in Windows 3.11 worked a lot better than this and was actually semi-acceptable as a soundcard replacement. Wait - aren't we at version 3.11 now, too? So shouldn't this now just work, too? Especially given our very advanced timer handling compared to those primitive OSes, I'd definitely expect device performance to be somewhat *better* not worse... > That facility is important because persons in poorer > places have old computers without sound cards. Indeed. While this argument is getting harder to make by the minute (with many soundcards builtin, almost for decades), it does have some merit (even if it's just to provide a minimally usable replacement for a cheapo broken soundcard hardware, or for - God forbid! - soundcard hardware unsupported by Linux). Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- 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: weird keyboard issue (ps/2 port?) 3.9.x/3.10.x?
On Tue, Aug 27, 2013 at 09:18:37PM +0200, Geert Uytterhoeven wrote: > On Tue, Aug 27, 2013 at 7:41 PM, Andreas Mohr wrote: > > while :; do clear; cat /proc/interrupts; sleep 1; done > > watch cat /proc/interrupts > > (yes, I spent ca. 15 years of my life using a similar loop ;-) Urgh, how did I manage to forget about that? :) However my solution surely achieves faster more better colorfully HD since it's base POSIX shell rather than heavy-handed "watch" dependency :) Andreas Mohr -- 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: [RFC PATCH] ES938 support for ES18xx driver
Hi,
> ES938 is controlled by MIDI SysEx commands sent through card's MPU401 port.
>
> The following patch works but has a problem: the midi port cannot be used by
> userspace applications. Opening and closing the rawmidi device on each control
> change would probably work (as long as the port is not used by an application)
> but that just does not seem right. Is there a way to cleanly fix this?
Just to clarify matters:
The story here was a bit split, but then I got it:
you're saying that since ES938 control is via MIDI SysEx,
these operations will occupy MIDI resources at least while controlling ES938
and therefore they're unavailable for userspace.
Don't tell me we'd require a MIDI access multiplexing layer which perhaps does
not exist yet...
> (There are two problems: 3D level does not have any effect and alsamixer does
> not display the TLV dB values - but don't know why).
Hmm, I'm rather in the dark here as well - however from my driver experiences
the actually sort-of standardized 3D level control
may have some "weird" deviations (at least when talking AC97 or pseudo-AC97)
such as different bitmask indices or possibly even inverted volume operation
(background: azt3328 is pseudo-AC97, thus it has some deviations).
Sorry for not knowing any more helpful hints...
Hmm, or perhaps ES938_REG_POWER needs some special values configured
to have 3D sound effects powered up, too?
OTOH if this is a simple non-DSP implementation then 3D probably is implemented
via delay lines etc., so perhaps it is so simple that it does not have a
special "enable power" switch after all.
Oh, and BTW, my azt3328.c said:
* - (non-bug) "Bass/Treble or 3D settings don't work" - they do get evaluated
*if you set PCM output switch to "pre 3D" instead of "post 3D".
*If this can't be set, then get a mixer application that Isn't Stupid (tm)
*(e.g. kmix, gamix) - unfortunately several are!!
So perhaps ES938 has (perhaps since it might more or less conform to certain
standards specs?) another control for PCM output switch as well
which would need implementing or simply isn't set properly?
(to clarify, we're talking about a switch which would cause output signal
to be grabbed pre or post the 3D manipulation block)
> + if (snd_es938_init(&chip->es938, card, 0, 0) == 0)
> + printk("es938 found!\n");
Perhaps we could have a more verbose message here?
That ES938 surely must have some human-readable characteristics...
(hmm, what about "ES938 3D audio effects processor found!"?)
((or "Detected ..."))
> + /* try to read a register to detect chip presence */
> + if (snd_es938_read_reg(chip, ES938_REG_MISC, NULL) < 0)
> + return -ENODEV;
Perhaps that check is not specific enough, i.e. it might be useful
to figure out a more precise check?
Thanks a ton for enhancing the feature set of certain sound cards :))
Andreas Mohr
--
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: [RFC PATCH] ES938 support for ES18xx driver
Hi, On Sun, Sep 15, 2013 at 10:25:45PM +0200, Ondrej Zary wrote: > On Sunday 15 September 2013 20:49:02 Andreas Mohr wrote: > BTW. I've got an AZT3328 card and it works fine with your driver. Thanks for > it. What!?!? I didn't quite expect any kernel dev to have that one, too ;) (got several commits sitting here and waiting for submission though) > I'm thinking about doing some reverse-engineering of thunderbird-based sound > cards (VLSI Thunderbird - Aztech PCI 368-DSP, Thunderbird Avenger - Philips > Acoustic/Seismic/Rhythmic Edge). Oh, nice. I've got the Aztech PCI 368-DSP, too (that was somewhat obligatory due to having written another Aztech card driver...). And yeah, the PCI 368 (etc.) series does seem to be some rather heavy support hole indeed, IIRC (especially as it's more modern PCI-based and not ISA). > > So perhaps ES938 has (perhaps since it might more or less conform to > > certain standards specs?) another control for PCM output switch as well > > which would need implementing or simply isn't set properly? > > (to clarify, we're talking about a switch which would cause output signal > > to be grabbed pre or post the 3D manipulation block) > > The good thing is that there's a datasheet available for ES938 - e.g. at > http://www.datasheetarchive.com/ES938-datasheet.html > > The 3D switch works but the level doesn't. Maybe I should use only the 3 > specific level values from the datasheet and not a variable scale. Or just > remove the level control completely as Windows driver does (there's only a 3D > switch). Hmm. Perhaps they removed it "Since It Does Not Work"? ;-P Thanks for hinting at the TLV control dB values thingy! Didn't know that such thing existed, thus azt3328 does not have it (yet?). > > Perhaps we could have a more verbose message here? > > That ES938 surely must have some human-readable characteristics... > > (hmm, what about "ES938 3D audio effects processor found!"?) > > ((or "Detected ...")) > > Yes, that's wrong - it's only for testing purposes. There should probably be > no message at all as the es18xx driver itself does not display anything if > everything is OK. ...or that, yeah. > > Perhaps that check is not specific enough, i.e. it might be useful > > to figure out a more precise check? > > snd_es938_read_reg() checks that the returned data match the format used by > ES938. Maybe we can reread all the register values back after writing to be > sure. Is there any chip ID/version register to be identified? Andreas Mohr -- 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: [RFC PATCH] ES938 support for ES18xx driver
On Sun, Sep 15, 2013 at 11:04:26PM +0200, Ondrej Zary wrote: > On Sunday 15 September 2013 22:35:20 Andreas Mohr wrote: > > What!?!? I didn't quite expect any kernel dev to have that one, too ;) > > Don't remember where I got it from but it looked nice so I bought it :) Yup, e.g. the builtin amp is quite nice. > > Thanks for hinting at the TLV control dB values thingy! Didn't know that > > such thing existed, thus azt3328 does not have it (yet?). > > It's a nice thing, especially for cards that can go above 0 dB. You then know > that the sound can be distorted when you set e.g. PCM volume too high. Hmm, any hint how to precisely do dB values normalization scaling, for a card where this is not documented? Or perhaps that's actually easy - haven't thought about it... > > Is there any chip ID/version register to be identified? > > No, there are only 8 registers, all(? - haven't tested) R/W. OK, but possibly they happen to be creating another virtual register mapping range? (i.e. index/data register combo?) Andreas Mohr -- 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: [RFC PATCH] ES938 support for ES18xx driver
Hi,
On Mon, Sep 16, 2013 at 10:20:54PM +0200, Ondrej Zary wrote:
> +static int snd_es938_read_reg(struct snd_es938 *chip, u8 reg, u8 *out)
> +{
> + u8 buf[8];
> + int i = 0, res;
> + u8 sysex[] = { MIDI_CMD_COMMON_SYSEX, 0x00, 0x00, ES938_ID,
> +ES938_CMD_REG_R, reg, MIDI_CMD_COMMON_SYSEX_END };
> + unsigned long end_time;
> +
> + snd_rawmidi_kernel_write(chip->rfile.output, sysex, sizeof(sysex));
> +
> + memset(buf, 0, sizeof(buf));
> + end_time = jiffies + msecs_to_jiffies(100);
> + while (i < sizeof(buf)) {
> + res = snd_rawmidi_kernel_read(chip->rfile.input, buf + i,
> + sizeof(buf) - i);
> + if (res > 0)
> + i += res;
> + if (time_after(jiffies, end_time))
> + return -1;
> + }
Forgive me, but I seem to faintly remember that it's preferred for
user code to tend towards non-jiffies-based timing (IIRC due to
NOHZ efforts etc.).
So if that actually is the case, then one might want to change it to
less jiffies-dependent handling (use non-jiffies helpers), but then how?
> +static void snd_es938_write_reg(struct snd_es938 *chip, u8 reg, u8 val)
> +{
> + u8 sysex[] = { MIDI_CMD_COMMON_SYSEX, 0x00, 0x00, ES938_ID,
> +ES938_CMD_REG_W, reg, val, MIDI_CMD_COMMON_SYSEX_END };
> +
> + snd_rawmidi_kernel_write(chip->rfile.output, sysex, sizeof(sysex));
snd_rawmidi_kernel_write() is prototyped as const unsigned char *buf,
so perhaps...
const unsigned char buf[] = ...;?
(static const probably not so useful
e.g. since static const may be rather prone to cache misses)
Though personally I do favour u8, since "char" seems so unsuitably stringy -
but the prototype currently doesn't offer it typed that way...
(Almost-)Reviewed-By: Andreas Mohr
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] workqueue: defer to waiting stop_machine
> Isn't the problem that the kworker wouldn't yield to the higher > priority stopper task while a work item keeps requeueing itself if > preemption is not enabled? If so, isn't the correct solution just > adding cond_resched() in the work item processing loop? The analysis > and solution seem to have gone a bit stray While I did not quite follow the very fine and detailed analysis, I had the same feeling about it. The previous solution seemed less preferable e.g. for two reasons, from a modularity/dependency POV: - required a very specific (code smell?) stop_machine handling dependency in work queue code (machine stop handling arguably definitely is a corner case, and thereby supposed to remain just that!) - new stop_machine_pending() helper is pretty bloated, and called in a semi-hotpath to boot (since it's using && operators rather than ||, seems like it would be called pretty much every time) Preemption checks being expected to be much more general and widespread thus seems like a much better fit. Or, to put it another way, could it be that that extra very specific stop_machine check was simply added since due to missing preemption checks we were busy-handling there and thus not getting back to standard handling areas where some *usual*, *hotpath/mainstream* stop_machine checks would have been made? If so, perhaps there actually are some other cases of wasteful stop_machine check code sites in the kernel where instead we could simply have a much cheaper reschedule done, thereby go back to hitting one central (and thus cache-hot) code site with stop_machine check etc.? Afraid of having stated the glaringly obvious ;), Andreas Mohr -- 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/
[YASB] Re: Linux 3.7-rc7
Hello, JFYI: Yet Another Suspend Breakage, it seems (hopefully someone can contribute to and further nail down this issue). Working: vmlinuz-3.7.0-rc5-00068-gc5e35d6 (HEAD possibly unknown?) Failing: vmlinuz-3.7.0-rc7-00179-g2db18aa (HEAD 3c46f3d6406b1d0c53575774b2d1fd013cd7f76f) Athlon XP 32bit VIA 8K5A2+. Florian Fainelli (1): x86/ce4100: Fix pm_poweroff sounds like it *might* happen to be a candidate (I could try to add a revert on top, of certain likely candidates). I started some initial pm debugging (Documentation/power/basic-pm-debugging.txt), and it started hanging once progressing from "devices" to "platform" in /sys/power/pm_test . I could do more invasive debugging (and unloading modules at random, too), however given that I'm currently spending almost days debugging my third(!) non-working USB storage device in one year, I'm somewhat less inclined. As a side note, support status in (admittedly terribly complex, and certainly very challenging given Windows' usual dirty non-spec tricks in this area as well) USB storage areas seems to be nothing short of *terrible*. At the current rate, there's an almost one-in-three chance to end up with a dud when shopping for storage devices, it seems. This situation should DEFINITELY see improvement, ideally via a concerted effort (and finally get those lazy vendors involved, too!). It really cannot be that hard to buy devices at random and plug into a large selection of random hardware to verify that everything works in a most compatible way!! Internet forums are full of stories about device failures on *Linux*, with some of the usual recommendations being "oh yeah, you need to disable ehci_hcd" (what a terrible "workaround") or "use irqpoll" (dito) [none of which helped in my two remaining cases]. So, all the usual problems (suspend breakage, USB storage) alive and kicking... Crawling back into my corner, Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- 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: [YASB] Re: Linux 3.7-rc7
Hi,
On Mon, Dec 03, 2012 at 11:39:07AM -0800, Linus Torvalds wrote:
> On Mon, Dec 3, 2012 at 11:33 AM, Andreas Mohr wrote:
> > Florian Fainelli (1):
> > x86/ce4100: Fix pm_poweroff
> >
> > sounds like it *might* happen to be a candidate (I could try to add a
> > revert on top, of certain likely candidates).
>
> That can only matter if you select support for CONFIG_X86_INTEL_CE
> ("CE4100 TV platform") which you should never do unless you actually
> compile for that platform.
OK, nevermind.
> So it's something else (or you have an insane config file). Bisection
> would be wonderful.
At least the config file part of my side seems to be sane ;)
Will try script to unload half of all drivers etc.
(heavy amounts of bisection wouldn't be joyful on this box).
I failed to mention the effects:
Suspend starts, disk does spin down, yet display backlight stays
until finally monitor blanks.
Thanks,
Andreas Mohr
--
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: [YASB] Re: Linux 3.7-rc7
Hi, On Mon, Dec 03, 2012 at 08:48:17PM +0100, Andreas Mohr wrote: > Will try script to unload half of all drivers etc. > (heavy amounts of bisection wouldn't be joyful on this box). > > > I failed to mention the effects: > Suspend starts, disk does spin down, yet display backlight stays > until finally monitor blanks. Unloading *all* unloadable modules didn't help. Current status: $ git bisect log git bisect start # good: [f4a75d2eb7b1e2206094b901be09adb31ba63681] Linux 3.7-rc6 git bisect good f4a75d2eb7b1e2206094b901be09adb31ba63681 # bad: [3c46f3d6406b1d0c53575774b2d1fd013cd7f76f] Merge branch # 'for-3.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq git bisect bad 3c46f3d6406b1d0c53575774b2d1fd013cd7f76f # good: [35f95d228e55eebdc87b5c0dbdecc46884f476a6] Merge tag # 'for-linus-20121123' of git://git.infradead.org/mtd-2.6 git bisect good 35f95d228e55eebdc87b5c0dbdecc46884f476a6 # good: [e9296e89b85604862bd9ec2d54dc43edad775c0d] Merge # git://git.kernel.org/pub/scm/linux/kernel/git/davem/net git bisect good e9296e89b85604862bd9ec2d54dc43edad775c0d Currently processing a95251b8bac4a91a43db795a7193545dac65f4f4 . So far everything in the normal, no interim (build) breakage etc. Andreas Mohr -- 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/
Look Ma, da kernel is b0rken
Hi, drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi': drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:66:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:67:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] That's already the second less enticing -Wlogical-op issue which was discovered by accident during less than two days of my happy(?) activity of kernel suspend breakage bisection. Why oh why, as a rather *very* critical piece of software, can't the kernel use sufficiently aggressive warning levels *by default*?? IMHO it's simply NOT ACCEPTABLE to have such sloppiness creep into the daily bandwagon of kernel development life (or should I say: being mandated to creep in?). Result: whichever default warning level you set *will* end up as The New Normal, and all those warnings which then remain able to rear their ugly heads according to the chosen default level will be fixed by the community eventually, and *most others won't* (or at least not in time). The amount of warnings spewn by make W=3 (or even W=2) is simply shocking IMNSHO. And there can always be an argument that most of such warnings are fixable. If not directly (e.g. because analysis of that warning type is partially unreliable), then by actively reworking code into something slightly different. So, unless there are very hard and *justified* reasons for keeping builds at such lame-*ss defaults (such as automated compliance test runs which may not fail - but in such cases one could argue that *those* uses should then be required to manually lessen *their* warning level settings), I would strongly vote for having a hard discussion about the status quo. As a somewhat aggravating comment, please note that this warning actually seems to date back to 1da177e (initial repository build) according to blame on that file. Andreas Mohr P.S.: sorry for the subject line ;) -- 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: Look Ma, da kernel is b0rken
Hi, On Wed, Dec 05, 2012 at 03:27:56PM +, Alan Cox wrote: > > On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote: > > > Hi, > > > > > > drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi': > > > drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively > > > exhaustive tests is always true [-Wlogical-op] > > > drivers/pnp/pnpacpi/core.c:66:2: warning: logical 'or' of collectively > > > exhaustive tests is always true [-Wlogical-op] > > > drivers/pnp/pnpacpi/core.c:67:2: warning: logical 'or' of collectively > > > exhaustive tests is always true [-Wlogical-op] > > > > > > > > > That's already the second less enticing -Wlogical-op issue > > > which was discovered by accident during less than two days > > No it's not. It's been reported in bugzilla. I sent patches ages ago. > They were ignored. Coverity has had it tagged for years (and a ton more > of them you've not noticed yet) And that additional new info bit now arriving is supposed to improve on the total set of the general state of affairs as I'm observing it (and thus to appease me, sufficiently), how exactly? ;) (well, admittedly it was new to me since I didn't bother with doing any more research after discovering that bug after also having endured countless pages of dangerously obscuring completely *superfluous* warning spew scrolling by) Let's see: - we've got this *core layer* (right?) bug originally appearing in <= 2.6.10 (2004, i.e. 8+ years). - we've got a janitorial project which does not (possibly "cannot"?) do a sufficiently clean work (as evidenced by a metric crap ton of header-side woefully repeated warnings persisting over perhaps half a year in my observation, with W=2 or W=3) - we've got how many dozen dozen kernel maintainers or "interested" persons who I'd imagine would be a sure-fire method to get such issues fixed in due time, and how many distributors or embedded companies who I'd imagine would help towards doing a quite large amount of effective testing/verification/housekeeping work in a controlled manner? (which would include regularly/mechanically keeping an eye on a larger set of *non-default* compiler warnings, too) - we've got how many kernel-related tools to assist in such efforts, which then were not being followed sufficiently? [Coverity] - and now your reply seems to indicate we additionally have a less optimal response time for such fixes, too? If that isn't a strong indicator of having to spend some time on rethinking possibly automated kernel development core infrastructure or due process... Heck, the Linux kernel isn't a "Joe's Garage works" effort - it's a *very* widely used *very* public project, thus you'd think with its clout and resulting manpower it should be able to easily afford things such as near-eradication of warnings (and thus the resulting much improved precision in *successfully* letting mere users pinpoint single critical warnings as near-soon as they newly appear, due to a low amount of warnings even on a high warning level). I'm afraid even with my measly very specific project/laughable manpower I've got certain parts in place which go beyond of what the kernel chooses to use. As an additional factor, the C-based kernel has the convenience of not even having to spend effort on the large set of additional compiler warnings that the developer is gifted with in C++ space! For gcc -Wlogical-op, it seems many articles/discussions were in 2009 time, thus there admittedly probably wasn't such a large window of opportunity to get this bug discovered - however that's still no excuse for the very visible showering of simple warnings when enabling advanced levels. Thanks to Borislav Petkov for his reply, too - however I'd like to state that given this lack of tooling/attention writing a mail in this more special manner was fully justified IMPHO. Andreas Mohr -- 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: Look Ma, da kernel is b0rken
On Wed, Dec 05, 2012 at 05:44:10PM +0100, Borislav Petkov wrote: > On Wed, Dec 05, 2012 at 05:39:05PM +0100, Andreas Mohr wrote: > > Thanks to Borislav Petkov for his reply, too - > > however I'd like to state that given this lack of tooling/attention > > writing a mail in this more special manner was fully justified IMPHO. > > Ok, you've stated more than clearly that you're pissed with the current > situation - I think we all got that. Hohumm. > Now, how do you suggest we change it constructively and how are you > willing to help? IMHO that's some common "misconception" - namely that innocent observing by-standers are fully expected to get involved in the process. Not necessarily, however (that's what domain experts are there for - since people are well-advised to concentrate on the activities that they are commonly involved with/do best). I would be willing to handle corrections in the areas of drivers I was working on (some corrections were already queued locally). For scripted mechanisms (e.g. usefully nagging people as stated in another posting), someone else would have to work on it I'm afraid. Thanks, Andreas Mohr -- 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: [YASB] Re: Linux 3.7-rc7
Hi, got through all steps after all, and the ghost vanished. Perhaps I did some silly mistake (marked that original master HEAD as "bad" despite not actually having run that but rather some local seemingly innocuous modifications - that will teach me for sure...). Or perhaps it was something about the weird (to put it mildly) gcc ICEs that I got when doing next bisection build on *some* of those kernels... (i.e., some earlier effects from that, thus causing the problem) A memtest run would be in order... (fortunately I'm one generation post magnetic core memory on this "box" :-)) Just saw the -rc8 announce, thus I wanted to clarify status now, but I'm still only 98% solid about this bisection result here. Probably best to go straight ahead to -rc8. Andreas Mohr -- 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: Look Ma, da kernel is b0rken
Hi,
On Wed, Dec 05, 2012 at 01:38:53PM -0800, Andrew Morton wrote:
> Bjorn had a review comment which appears to remain unaddressed:
>
> : The original is definitely broken.
> :
> : I think the corrected test allows PNP IDs containing '@', which
> : doesn't appear legal per sec 6.1.5 of the ACPI 5.0 spec. Should this
> : be
> :
> : + if (!('A' <= (c) && (c) <= 'Z')) \
> :
> : instead?
I hate having to rain on the parade again ;)
I just developed some doubts, by accident again,
by getting dangerously near sound/isa/als100.c snd_als100_pnpids:
there are many IDs with '@' embedded (at least in this ISA-based PnP code),
thus I guess that code may have had its justification (unless ACPI 5.0
is clearly fully authoritative for this space and thus '@' does not have any
business there any more).
Dito e.g. isa/cmi8330.c.
Hmm, anyone deeply familiar with ISA PnP ID magic? :)
Andreas Mohr
--
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: Look Ma, da kernel is b0rken
Hi, On Fri, Dec 07, 2012 at 06:44:05PM +0100, Borislav Petkov wrote: > On Fri, Dec 07, 2012 at 05:52:18PM +0100, Andreas Mohr wrote: > > Hmm, anyone deeply familiar with ISA PnP ID magic? :) > > Even if this is violating the ACPI spec, any fix for this needs to be > tested on the hardware (and I can very well imagine that the hardware > might be violating the spec too, nothing new here). > > So even if you had a fix, you need to run it on the hardware to verify > that it actually works. And that demand actually applies to both the '@' change (questionable) and the much less disputed (obviously correct) wrong conditional fixup, since both introduce a notable change (either large, or possibly improper) in behaviour. > So the actual practical question turns into: do you have such hardware > to verify your or anyone else's fix on? Not the ALS100 (only ALS4000 here). I possibly have some other ISA hardware, but probably none which contains '@' data in their PnP id struct. The driver for the well-known case of ISDN PnP cards does not seem to contain it. However ISTR that CMI8330 was quite widespread (did I have one? Do I??). For identification, see http://www.yjfy.com/C/C-Media/soundchipset/CMI8330A.htm I'm afraid I should get an old system back up and running, exactly for such validation work cases (and perhaps so should a select few other developers, too). BTW, "my" fix? I thought that everybody had come to the conclusion by now that I merely pointed out (in no uncertain terms to boot) that something was broken :) Andreas Mohr -- 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/
[PATCH] usbnet: improve/fix status interrupt endpoint interval
>From 307685fe8e6dfc8181e30167b9c31479332cb22f Mon Sep 17 00:00:00 2001
From: Andreas Mohr
Date: Sun, 2 Jun 2013 20:37:05 +0200
Subject: [PATCH] usbnet: improve/fix status interrupt endpoint interval
tweaking.
- failed to take super-speed into account
- <= full-speed seems to have wrong value (specified as frames [ms],
thus 3 is not suitable to achieve 8ms)
Value 8 now managed to reduce powertop wakeups from ~ 540 to ~ 155
- add detailed docs and question marks about current practice
---
drivers/net/usb/usbnet.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
Found this with MCS7830 on a full-speed USB 1.1 port (Inspiron 8000).
Good to have a rusty notebook with noisy PSU coils, else it would
have taken a lot longer to nail it ;)
Tested on -rc4, checkpath.pl:d.
Signed-off-by: Andreas Mohr
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 06ee82f..b6e9569 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -231,8 +231,23 @@ static int init_status (struct usbnet *dev, struct
usb_interface *intf)
maxp = usb_maxpacket (dev->udev, pipe, 0);
/* avoid 1 msec chatter: min 8 msec poll rate */
+ /* High/SuperSpeed expresses intervals in microframes
+* (in logarithmic encoding, PRIOR to encoding in URB)
+* rather than frames.
+* Thus, for >= HighSpeed: == X [microframes] * 125us [-> 8ms],
+* <= FullSpeed: == X [ms] [-> 8ms].
+* Finally, it's questionable whether we'll even get away unscathed
+* with doing such rate tweaking at all:
+* bInterval value is declared as being a hard demand by a device
+* in order to guarantee having its I/O needs serviced properly...
+* if we don't do this, then... [overruns], [fire], [apocalypse]?
+* If this turns out to be problematic, such policy should be moved
+* to individual drivers (indicate flag to [dis]allow rate tweaking
+* as tolerated by specific devices).
+*/
period = max ((int) dev->status->desc.bInterval,
- (dev->udev->speed == USB_SPEED_HIGH) ? 7 : 3);
+ ((dev->udev->speed == USB_SPEED_HIGH) ||
+(dev->udev->speed == USB_SPEED_SUPER)) ? 7 : 8);
buf = kmalloc (maxp, GFP_KERNEL);
if (buf) {
--
1.7.10.4
--
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/
[PATCH] usbnet: mcs7830: improve workaround against unreliable link status.
>From d4bf85d0c6776bf4b15a0eea7772f9c55cef3daf Mon Sep 17 00:00:00 2001
From: Andreas Mohr
Date: Sun, 2 Jun 2013 22:24:35 +0200
Subject: [PATCH] usbnet: mcs7830: improve workaround against unreliable link
status.
- to guard against spurious link loss, try to improve precision
by taking into account full-duplex / 100Mbps bits as well
- add actual status enums rather than using open-coded ints
- MCS7830 status data is word-sized, thus do access it that way
---
drivers/net/usb/mcs7830.c | 74 +++--
1 file changed, 72 insertions(+), 2 deletions(-)
Realized that link state is unreliable indeed (sometimes causing
some intermediate status changes even with that averaging happening),
thus I was wondering how to improve it.
First thing was to think of something which we might be doing wrong in general,
but I couldn't come up with much.
Thus I concentrated on the status bits that were incoming, where I realized
that full-duplex / 100Mbps bits are a strong indication of an actual
link. IOW, update code to consider link lost only if link loss bit is active
and neither full-duplex nor 100Mbps is indicated.
Of course a half-duplex 10Mbps connection (BNC hub?) will not be happy
then. Sucks, but that's life.
Anything else that someone might come up with on why status is that
unreliable? Perhaps that's a common phenomenon with some PHY mechanisms?
Tested on -rc4, checkpath.pl:d.
Signed-off-by: Andreas Mohr
Thanks,
Andreas Mohr
diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
index 03832d3..0c1543b 100644
--- a/drivers/net/usb/mcs7830.c
+++ b/drivers/net/usb/mcs7830.c
@@ -114,6 +114,43 @@ enum {
/* [7:6] reserved */
};
+/* Bits within one status word in status interrupt callback data */
+enum {
+ MCS7830_STATUS_ETHER_FRAME_OK = 0x0001,
+ MCS7830_STATUS_RETRIES_MORE_THAN_16 = 0x0002,
+ MCS7830_STATUS_COLLISION_OCCURRED_AFTER_64BYTES = 0x0004,
+ MCS7830_STATUS_PACKET_ABORTED_EXCESS_DEFERRAL = 0x0008,
+ /* 9:4 reserved (all zeroes) */
+ MCS7830_STATUS_FULL_DUPLEX_EN = 0x0400,
+ MCS7830_STATUS_SPEED_100MBPS= 0x0800,
+ MCS7830_STATUS_MIIM_INTERRUPT = 0x1000,
+ /* Link flag is UNRELIABLE, on both 7830 and 7832!
+* While pulling the cable always seems to result in a clean 0x2000,
+* sometimes in between (especially when transfers are interfering?)
+* there's 0x2XXX values as well, but they always seem to be 0x2cXX
+* (at least for full-duplex, 100Mbps operation).
+* Thus the only more reliable way to tell apart actual link loss
+* from pseudo loss is to query for "link loss" *and*
+* "both full-duplex *and* 100Mbps *not set*". Which obviously means
+* that a half-duplex, 10Mbps setup
+* likely will never be able to indicate link reliably :(
+* Plus, I'm wondering whether we (or the kernel?)
+* are simply doing something wrong which causes the device to act up
+* (e.g., intermingling frame transfers with status transfers
+* in a sufficiently problematic way [inner-device race conditions?]).
+* Also, averaging several status bools is not very useful since:
+* - it directly depends on polling frequency
+* - (and thus) that count may still not be enough --> mis-detection
+* Perhaps on link loss it's somehow doable to subsequently do
+* an actual PHY request (perhaps not in status callback?)
+* which would hopefully reliably indicate status.
+*/
+ MCS7830_STATUS_MIIM_LINK_DOWN__UNRELIABLE = 0x2000,
+ MCS7830_STATUS_TX_STATUS_VECTOR_BITS_VALID = 0x4000,
+ MCS7830_STATUS_SRAM_HAS_FRAMES_PENDING = 0x8000
+};
+
+
struct mcs7830_data {
u8 multi_filter[8];
u8 config;
@@ -559,14 +596,47 @@ static int mcs7830_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
static void mcs7830_status(struct usbnet *dev, struct urb *urb)
{
+ /*
+* TODO: since status polling is very painful (>> 100 wakeups / second),
+* could add a module param
+* disable_status_poll
+* "Disable polling of status interrupt EP (avoid excessive wakeups)."
+* where one would set the .status member to NULL
+* (but that's currently not doable since the struct is const).
+*/
+
u8 *buf = urb->transfer_buffer;
- bool link, link_changed;
+ u16 *statuswords = (u16 *)buf;
+ bool link_might_be_lost, link, link_changed;
struct mcs7830_data *data = mcs7830_get_data(dev);
if (urb->actual_length < 16)
return;
- link = !(buf[1] & 0x20);
+ netdev_dbg(dev->net,
+ "status %04x %04x %04x %04x %04
Re: [PATCH] usbnet: improve/fix status interrupt endpoint interval
Hi, On Wed, Jun 05, 2013 at 09:22:25AM +0800, Ming Lei wrote: > On Wed, Jun 5, 2013 at 2:28 AM, Andreas Mohr wrote: > > > > From 307685fe8e6dfc8181e30167b9c31479332cb22f Mon Sep 17 00:00:00 2001 > > From: Andreas Mohr > > Date: Sun, 2 Jun 2013 20:37:05 +0200 > > Subject: [PATCH] usbnet: improve/fix status interrupt endpoint interval > > tweaking. > > > > - failed to take super-speed into account > > - <= full-speed seems to have wrong value (specified as frames [ms], > > thus 3 is not suitable to achieve 8ms) > > The above change is correct. > > > Value 8 now managed to reduce powertop wakeups from ~ 540 to ~ 155 > > It means that your device only returns current link status instead of link > change. IMO, it isn't a good behaviour for the device. I don't quite understand that. The way I see it is that there's the "20 times same value" averaging, and once that was successful, a link change gets communicated (usbnet_link_change()). Thus that merely results in a *delay* in signalling the link change... > In fact, you still can increase the period only for your device, for example, > 128ms/256ms/512ms should be accepted. Possibly. > > - add detailed docs and question marks about current practice > > But the doc need to be fixed. Hmm. > > /* avoid 1 msec chatter: min 8 msec poll rate */ > > + /* High/SuperSpeed expresses intervals in microframes > > +* (in logarithmic encoding, PRIOR to encoding in URB) > > +* rather than frames. > > +* Thus, for >= HighSpeed: == X [microframes] * 125us [-> 8ms], > > +* <= FullSpeed: == X [ms] [-> 8ms]. > > +* Finally, it's questionable whether we'll even get away unscathed > > +* with doing such rate tweaking at all: > > +* bInterval value is declared as being a hard demand by a device > > It isn't a hard demand, which only means the poll interval by which HC > sends IN token to device. I believe this number is meant to be a hard demand by the *device*, since a device is the authoritative party to know best about its own servicing requirements. Or, IOW, the thing that is a USB descriptor is to be seen as a *protocol* where a device signals its requirements (hopefully accurately, though!). And if it indicates a 1ms bInterval (which is "the requested maximum(!!) number of milliseconds between transaction attempts" [lvr usbfaq]), then one could argue that the servicing party (the kernel) damn well ought to follow through (unless it reliably knows that it can violate some parts of these demands without getting caught). > > +* in order to guarantee having its I/O needs serviced properly... > > +* if we don't do this, then... [overruns], [fire], [apocalypse]? > > Not so serious, if one packet is ready, the late poll from HC may still > get the packet since device can buffer the packet, but if it is too late, > the successor packet might be missed by device. Is proper damage-less (overflows...) handling here a promise/guarantee that's made by the USB specs? Otherwise I wouldn't be so confident that a device is acting this way ;) > For usbnet, generally speaking, the interrupt pipe is for polling the > link change, which is a very low frequency event, so you don't need to > worry about missing events if the interval is increased. Yeah, but then those status bits also contain other error info for every packet processed, thus it's also very useful to achieve polling that's frequent enough to properly grab info for all transferred ether frames, rather than merely concentrating on link change info. > > +* If this turns out to be problematic, such policy should be moved > > +* to individual drivers (indicate flag to [dis]allow rate tweaking > > +* as tolerated by specific devices). > > Yes, we can add quirk for such kind device by increasing polling > interval. Sure, but that handling seems a bit static. An ideal service level would be getting notified of all link changes in a sufficiently slow way, *and* always catching status flags of *all* frames, too. > > +*/ > > period = max ((int) dev->status->desc.bInterval, > > - (dev->udev->speed == USB_SPEED_HIGH) ? 7 : 3); > > + ((dev->udev->speed == USB_SPEED_HIGH) || > > +(dev->udev->speed == USB_SPEED_SUPER)) ? 7 : 8); > > For the above change, please feel free to add my ack: > > Acked-by: Ming Lei Thanks! I'm still unsure how/whether to reword my documentation part, though. If you happen to have some ideas about some updates, that would be great. Thanks! Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbnet: improve/fix status interrupt endpoint interval
On Thu, Jun 06, 2013 at 09:33:28AM +0800, Ming Lei wrote: > On Thu, Jun 6, 2013 at 12:34 AM, Andreas Mohr wrote: > > Hi, > > > > On Wed, Jun 05, 2013 at 09:22:25AM +0800, Ming Lei wrote: > >> On Wed, Jun 5, 2013 at 2:28 AM, Andreas Mohr wrote: > >> > Value 8 now managed to reduce powertop wakeups from ~ 540 to ~ 155 > >> > >> It means that your device only returns current link status instead of link > >> change. IMO, it isn't a good behaviour for the device. > > > > I don't quite understand that. > > It is only concluded by the data you provided, when you get ~540 wakeups, > that means basically device will return data for each polling from HC. > > Also I am wondering why you get ~540 wakeups, instead of ~360(330 + 30) > (30 is guessed from ~155 wakup in 8ms interval) Hmm, right, with raw interval value having been specified as 3, this should have ended up as a cooked value of 3ms on full-speed, thus, given no further mcs7830 wakeup activity, we should remain at 330 something. Will investigate some more (e.g. a quick look at usbmon log timing, too). > Did you check intr_complete() returns OK every time? Good hint, will check. > >> It isn't a hard demand, which only means the poll interval by which HC > >> sends IN token to device. > > > > I believe this number is meant to be a hard demand by the *device*, > > since a device is the authoritative party to know best about its > > own servicing requirements. > > Actually, just see quirks for USB devices, there are many devices which > isn't worthy of trust, :-) I can easily believe that, having had my more than fair share of trouble already ;) > Also some problems should have been reported on current interval > value(larger than interval of endpoint) if it was hard demand, but luckly > looks no such report found. Yep. > As I said before, the link change is a low frequency event, so longer > interval used by usbnet driver should be OK, right? ...minus the status flags for frames, which surely would be interesting, too :) (and minus the frequency requirements of the mcs7830 link change "20 times" averaging mechanism, which expects a sufficiently high rate) > > Or, IOW, the thing that is a USB descriptor is to be seen as a *protocol* > > where a device signals its requirements (hopefully accurately, though!). > > And if it indicates a 1ms bInterval (which is "the requested maximum(!!) > > number of milliseconds between transaction attempts" [lvr usbfaq]), > > USB spec 2.0 doesn't say it is a maximum period between transactions, > and only mentions that is a "desired bus access period", see "5.7.4 > Interrupt Transfer Bus Access Constraints". Oh, so perhaps we have a usbfaq which actually is a FAQWBA? ;) (I should really have a look at the specs directly...) > > Is proper damage-less (overflows...) handling here a promise/guarantee > > that's made by the USB specs? > > Even there is overflow, it happens inside device, and it depends on > implementation of device itself. IOW, the device is free to blow up on its own. > > Otherwise I wouldn't be so confident that a device is acting this way ;) > > If so, you can use the dev->status->desc.bInterval, so you may complain > too much wakeup and CPU power consumed, and we need leverage. Yep, would surely be very useful to come up with a usbnet-side mechanism which flexibly keeps wakeups at a minimum, while still retrieving all data that it can get, and this for all devices(drivers) as handled by usbnet. > >> For usbnet, generally speaking, the interrupt pipe is for polling the > >> link change, which is a very low frequency event, so you don't need to > >> worry about missing events if the interval is increased. > > > > Yeah, but then those status bits also contain other error info for every > > packet > > processed, thus it's also very useful to achieve polling that's frequent > > enough to properly grab info for all transferred ether frames, rather > > than merely concentrating on link change info. > > Actually, most of usbnet drivers only use interrupt pipe to retrieve link > change(asix, smsc, ...). But if your device may provide other information > via interrupt pipe and your driver requires that, you may keep the > desired interval with extra power if it is worthy. > > Could you let us know what device may provide ether frame info > and how your drivers use that? That should be all devices supported by mcs7830.c, where it's probably the + MCS7830_STATUS_ETHER_FRAME_OK = 0x0001, + MCS7830_STATUS_RETRIES_MORE_THAN_16
Re: [PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt
On Thu, May 30, 2013 at 01:24:15PM -0600, Kris Rusocki wrote: > From: Kris Rusocki > > Now that binfmt_script is configurable, explain yet another possible > cause of boot failure (a script w/CONFIG_BINFMT_SCRIPT != y). Nice catch, and thanks for your effort! It's somewhat sad to see that that file remained at only one initial commit since 2010, thus thumbs up for your help! Docs in general seem to be a wee bit too unmaintained. Acked-by: Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt
Hi, On Mon, Jun 03, 2013 at 06:16:12AM -0500, Rob Landley wrote: > On 05/30/2013 03:33:10 PM, Andreas Mohr wrote: > >It's somewhat sad to see that that file remained at only one > >initial commit > >since 2010, thus thumbs up for your help! > > > >Docs in general seem to be a wee bit too unmaintained. > > Are you volunteering? Yeah (sort of ;) - in fact I keep piling up some doc updates locally and am just waiting for them to reach critical mass (but first I need to get some certain driver updates submitted anyway). Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: cover CONFIG_BINFMT_SCRIPT in init.txt
On Thu, Jun 06, 2013 at 08:33:20PM -0500, Rob Landley wrote: > No one person is an expert in every file in Documentation. My big > todo items are centered around librarian work: reorganizing the > layout of the directory so it's not a giant heap with everybody in > the world dumping stuff into the root directory, or weird little > crevices like pti/ and pps/ that have their own directory with one > file in it. Indeed, layout in kernel could be improved somewhat. Would be nice to find a layout that's suitably organized and more or less tries to *match* a good future (since it does not quite seem to exist yet) layout in Kconfig areas (where it's increasingly difficult to find things easily due to number of possibilities growing massively thanks to many new drivers and not enough obvious higher-level abstraction). Once you are asked to go beyond the third page in specific dialog-based menuconfig sections (e.g. drivers) you might just as well choose to enter minotaur labyrinth... :) Of course that's needed for manual changes only (make oldconfig does the rest), but it remains sufficiently painful. > Unfortunately, Documentation is the greatest source of bikeshedding > in the kernel. Even as the directory's nominal maintainer, I can't > say "translations don't belong in there, they belong on the web" > because Greg KH thinks they do so he'll check them in anyway. And > then nobody maintains them because anybody who can read the english > versions (and thus update the translations) doesn't need the > translations. Rock <-> hard place. :) The question here might simply be: what's Best Practice (tm) for dealing with translations? Unless that (I'm sure...) happens to not exist... ;) > There's functional stuff in there like the devicetree bindings. > There's a Makefile that compiles stuff under Documentation, and not > just the htmldocs but actual code. I still don't really know why... Huh? Wow. But then a git log -p Documentation/Makefile easily answers it: it's exclusively for "documentation-side" sample source files, to ensure that they always remain correctly buildable/working samples of source code. > Unfortunately, I only really get time to deal with this sort of > thing in the downtime between contracts, and last time I had a gap > the massive barn-door-locking after the kernel.org breakin still had > my account disabled because I hadn't been to an in-person conference > to get a new pgp key signed in years. (And now that I've been to a > conference and gotten one signed, I need to sit down and write a new > rsync replacement on top of kup because non-security people wrote a > bespoke security wrapper for kernel.org to replace shell access, > which means my old rsync script that updated http://kernel.org/doc > needs to be replaced with a rube goldberg monstrosity to do the same > thing in a much more complicated and less efficient way.) Ouch. Count me in on the huge "people in need of sufficiently recognized pgp signing" list, though ;) Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- 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/
libata / IDE cs5536: 80c cable detect issue (and worse?)
quot; by **pata_amd** (only!), on a 2.6.32 kernel, : i.e. a kernel long after the CS5536-specific pata_cs5536.c was added : in addition to the prior generic pata_amd.c. : I don't have lsmod output of that machine yet, but even now it strongly looks : like this config there does have both drivers and binds to the : **wrong** one (which quite likely is the actual reason for the : major data corruption screwup here, when reading between the lines of : the original patch thread at : http://www.mail-archive.com/linux-ide@vger.kernel.org/msg11033.html : (pata_amd most likely will not configure timings correctly, : which seems to have been the original reason for writing pata_cs5536.c). : Or would this be merely a limitation of that lspci version listing : claims for a single module only, yet both modules actually being : (correctly/rightfully?) loaded? : I'm planning to *somehow* (even on this hard-coded and older setup) : achieve getting pata_amd blacklisted tomorrow (blacklisting mechanisms : are/were very inconvenient and inconsistent), : to see whether indeed it's a very painful unremoved duplicate PCI ID issue : (existing since 2007 - I seem to have a good hand for uncovering : awfully long-standing issues ;-P). : : BTW 9272dcc2 "pata_cs5536: Add support for non-X86_32 platforms" : happened to also mention "pata_amd also supports cs5536 IDE controller" : - probably someone ought to have managed to realize to voice a complaint : at that time already ;) | PS Could we please move this discussion to | [2]linux-...@vger.kernel.org | mailing list if possible? : Indeed, I should just have done that. I had intended it to be a : preliminary private inquiry, but the usual consequences of that : (an ugly rewrite) are just too "challenging". : I chose to completely rewrite the mail since the reply contained : some weird non-ASCII indent operations (perhaps weird MUA?). Thanks! >From 374506ab6c3a57bd8890b5192b2047d7b96cb542 Mon Sep 17 00:00:00 2001 From: Andreas Mohr Date: Wed, 17 Jul 2013 18:49:58 +0200 Subject: [PATCH] CS5536: fix overly optimistic cable detect (handle libata API imprecision). We unconditionally indicated 80-pin cable capability in case *any* of Master/Slave devices had 80c cable presence configure-indicated by the BIOS. This, however, does not seem at all appropriate since CS5536 does manage its primary IDE's master/slave devices independently, both in cable detect and timing programming. Since libata does not offer API support for such per-device configurations yet, we really need to restrict things to the lowest common denominator. Signed-off-by: Andreas Mohr --- drivers/ata/pata_cs5536.c | 34 +++--- 1 Datei geändert, 31 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-) diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c index 0448860..f58bf04 100644 --- a/drivers/ata/pata_cs5536.c +++ b/drivers/ata/pata_cs5536.c @@ -146,10 +146,38 @@ static int cs5536_cable_detect(struct ata_port *ap) cs5536_read(pdev, CFG, &cfg); - if (cfg & IDE_CFG_CABLE) - return ATA_CBL_PATA80; - else + /* +* FIXME libata API limitation: +* CS5536 data sheet says +* "The IDE interface timing is completely programmable. +* Timing control covers the command active and recover pulse +* widths, and command block register accesses. The IDE +* data transfer speed for each device on each channel can +* be independently programmed allowing high speed IDE +* peripherals to co-exist on the same channel as older, +* compatible devices." and it does have per-drive-separate +* cable detect and timing programming bits for primary Master/Slave +* and in fact some devices (e.g. PCM-9375) do have e.g. +* directly-soldered (read: ~80c) CompactFlash primary Master +* and a 44pin (read: 40c) IDE primary Slave. +* However, libata only offers whole-ata_port cable detect callback +* that's arguably too imprecise for such hardware capabilities. +* Given this imprecision, we arguably are required for now +* to indicate the lowest common denominator, i.e. 40c in case +* *any* of Master/Slave does not indicate 80c support, +* in order to avoid imposing incorrect timing to the +* per-device-separate timing programming. +* This care seems especially important given evidence of +* existing other timing issues of CS5536: +* see errata 47 "UDMA Mode 5 stability issues" in PDF +* "AMD Geode (tm) CS5536 Companion Device Silicon Revision B1 +* Specification Update". +*/ + bool have_any_40c_only_device = (cfg & IDE_CFG_CABLE) < IDE_CFG_CABLE; + if (have_any_40c_only_device) return ATA_CBL_PATA40; + else + return A
Re: libata / IDE cs5536: 80c cable detect issue (and worse?)
Hi, forgot to mention that I had already added a libata.force=40c boot after my 80c config issue discovery which did successfully cause the "limiting to UDMA/33 due to 40c foo" dmesg yet where there's now initial but strong confirmation via reports that the resulting UDMA/33 limit did NOT manage to fix corruption issues, thus it's more strongly likely that the "bound to ill-suited pata_amd driver" (due to incorrectly configuring speeds, or due to not configuring speeds at all due to possibly BIOS not providing emulation of PCI register accesses to Geode bus, which would be properly supported by pata_cs5536 OTOH) thing is the actual reason and might fix it (fingers crossed). Thanks, Andreas Mohr -- 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: Re: libata / IDE cs5536: 80c cable detect issue (and worse?)
On Fri, Jul 19, 2013 at 12:40:38PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Thursday, July 18, 2013 08:25:41 PM Andreas Mohr wrote:
> > Hi,
> >
> > forgot to mention that I had already added a libata.force=40c boot
> > after my 80c config issue discovery
> > which did successfully cause the "limiting to UDMA/33 due to 40c foo" dmesg
> > yet where there's now initial but strong confirmation via reports
> > that the resulting UDMA/33 limit did NOT manage to fix corruption issues,
> > thus it's more strongly likely that the "bound to ill-suited pata_amd
> > driver"
> > (due to incorrectly configuring speeds, or due to not configuring speeds
> > at all due to possibly BIOS not providing emulation of PCI register accesses
> > to Geode bus, which would be properly supported by pata_cs5536 OTOH)
> > thing is the actual reason and might fix it (fingers crossed).
>
> UDMA/66 (and higher) requires 80-wire cable to work (if the vendor states
> that UDMA/66 is supported then UDMA/100 should also work on CS5536). UDMA/33
> should work just fine with 40-wire cable. Therefore this indeed sounds more
> like wrong driver being selected issue than a cable problem.
Hohumm, news flash:
We just found out that such image corruption
(not sure yet whether it's an *identical* case of corruption though)
also can occur when having the CF image written by a premium USB combo writer
on a *completely different machine* (should have done that counter check
somewhat earlier, sorry...).
IOW, this quite likely frees the driver from being the culprit
for our specific case, i.e. we're likely talking about a stupid software issue.
BUT, I'm still suspecting that we have a severe case of having the wrong driver
activated:
. lsmod:
sd_mod 25977 2
snd_cs5535audio 6485 0
ata_generic 2239 0
pata_cs5536 2294 0
pata_amd6641 1
libata117483 3 ata_generic,pata_cs5536,pata_amd
scsi_mod 106093 2 sd_mod,libata
cs5535_gpio 1756 0
Pray tell me, this does look like pata_cs5536 gets loaded
due to also containing the PCI ID, yet then fails to bind,
as opposed to pata_amd which does (reference count 1)?
We also tried the pata_cs5536.msr=1 boot parm:
[0.00] Kernel command line: [..] pata_cs5536.msr=1
libata.force=40c []
, and that did NOT cause the only recognizeable pata_cs5536-triggered
log message
printk(KERN_ERR DRV_NAME ": Using MSR regs instead of PCI\n");
to occur in dmesg, IOW this driver *is* inactive.
We only had a
[ 68.861778] pata_amd :00:0f.2: version 0.4.1
[ 68.864570] scsi0 : pata_amd
[ 68.865240] scsi1 : pata_amd
So, AFAICS, this leaves us with up to three (perhaps four?) corrections
that one would want to have:
- remove the woefully improper (forgotten!?!) CS5536 ID from pata_amd
(this correction is what one would want to have, and this would work fine,
right? Famous last words...)
- do a cable correction patch for libata side (I do think that indicating
40c if even one device is 40c-only is the way to go [as long as libata
cannot handle per-device settings], for safety reasons,
and if so that's probably also preferrable to advertising an UNK value,
since UNK would skip towards device-side cable detection
which might be unreliable in case ATA ID values (i.e., ATA_ID_HW_CONFIG)
happen to be incorrect,
e.g. especially in the case of CF cards (OTOH it specifically looks
for a 0x2000 bit being *set* for 80c indication,
thus it should be reliable after all since you'd expect ignorant/older
devices to provide zeroed fields only...)
- and what about cable correction patch for IDE side? Since IDE layer
cable probing sequence algo appears to be different ("why??"),
this might require advertising a different cable flag
- perhaps pata_cs5536 DMI quirk for that board, in case UDMA/100
(BIOS reports cable 0x03 value i.e. both 80c) happens to be too fast,
but given the advanced state of our discussion (pata_cs5536 driver
even completely inactive!!) and the DMI recognition issues that I reported
(empty strings) I don't think that's relevant, at least not now
Thanks,
Andreas Mohr
--
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: Re: libata / IDE cs5536: 80c cable detect issue (and worse?)
Hi,
On Fri, Jul 19, 2013 at 04:30:22PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Friday, July 19, 2013 02:26:53 PM Andreas Mohr wrote:
> > - do a cable correction patch for libata side (I do think that indicating
> > 40c if even one device is 40c-only is the way to go [as long as libata
> > cannot handle per-device settings], for safety reasons,
>
> Why would libata need per-device cable setting? There is only one cable
> per-port and it is shared between master/slave devices and some fancy
> embedded implementations of the cable (CF slot + connector to slave
> device) are not changing this fundamental design issue AFAIK.
I think it's simply because while the CF slot more or less obviously
seems to be rated "80c capable"-equivalent (due to its short connection?
c.f. various notebook situations),
*extension cable*(!) connections being connected to 44pin connectors
("ATA-44" ? conflicts with ATA/44 speed naming though)
seem to be rated as ATA/33 (https://de.wikipedia.org/wiki/ATA/ATAPI)
or IOW UDMA 2 (see various pages of 44pin CF adapter vendors).
So that means that you'd end up with a "mixed" capability primary port
(however my BIOS advertises 80c for both connectors,
which I suspect may not really be appropriate).
If you are able to argue hard evidence that this primary port Master/Slave
apparatus metallic layer connection is "one big shared resource"
(i.e. from a HF / EMI POV)
where behaviour ends up identical both for command and address timings
for all devices for all things practical that matter, then yeah.
But I have my doubts... (i.e., that it [address or command timings]
actually is to be seen in a device-connection-specific light,
to be reasonably safe).
But
https://en.wikipedia.org/wiki/Parallel_ATA
"For all modern ATA host adapters this is not true, as modern ATA host
adapters support independent device timing. This allows each device on
the cable to transfer data at its own best speed. Even with older
adapters without independent timing, this effect applies only to the
data transfer phase of a read or write operation. This is usually the
shortest part of a complete read or write operation."
seems to tend towards indicating that libata *should* have a per-device
form of .cable_detect(), unless "timing" != "cable type".
And, OTOH, you simply could pose the argument
that all that pseudo-intellectual reasoning does not matter,
since CS5536 actively *chose* to offer *per-device-specific* cable type bits
thus since it *does* offer such config possibility, libata *should*
support such (unless CS5536 somehow happened to be wrong in offering such
[useless?] liberty).
One way to extend libata to support such functionality might be
to have the driver set a flag to indicate that it has per-device cable type,
and then let libata serve a .cable_detect_per_device() or some such
instead.
Or choose to rework all drivers to have a per-device-extended
.cable_detect() instead (where most drivers would not [need to] make the
per-device distinction i.e. simply return the same setting for both).
> > and if so that's probably also preferrable to advertising an UNK value,
> > since UNK would skip towards device-side cable detection
> > which might be unreliable in case ATA ID values (i.e., ATA_ID_HW_CONFIG)
> > happen to be incorrect,
> > e.g. especially in the case of CF cards (OTOH it specifically looks
> > for a 0x2000 bit being *set* for 80c indication,
> > thus it should be reliable after all since you'd expect ignorant/older
> > devices to provide zeroed fields only...)
>
> Most controllers have per-port cable detection and CS5536 is being
> an exception here. I don't know how this detection is implemented in
> the hardware / BIOS but it could be that it is already taking into
> the account the drive side cable detection and that is why we have two
> values per-port. Please also note that the cable detection is only one
> of components of selecting device transfer speed which also involves
> comparing maximum host and device capabilities.
Yes, possibly because most controllers *do* have one single shared-medium
cable connection location per port only, whereas CS5536 (it only offers
one port in the first place, not two unlike many others!)
seems to treat the two connectors
(soldered-socket CF, and ATA-44 44pin, in the case of my system)
differently, *for that single port*.
CS5536 actually implicitly doing drive-side cable detection might be
a reason for the separate bits as you say, but I doubt it
(the controller would have to read out the device's ATA ID words, right??).
> Indicating 40c in case if one device detects the cable to be 40c and
> the other one detects 80c would unnecessarily punish the faster device
> (which would then need usage of kernel p
Re: [PCMCIA] Solved: No USB 2.0 (ehci) in PCMCIA slot on E7110
Hi, that means we're talking this one (have you had a look at Bugzilla #15014? Might be useful...): commit 35169529093be3bbef70afd3c4125e35cece7e03 Author: Wolfram Sang Date: Sun Jan 10 09:41:24 2010 +0100 pcmcia/yenta: add module parameter for O2 speedups O2-bridges can do read prefetch and write burst. However, for some combinations of older bridges and cards, this causes problems, so it is disabled for those bridges. Now, as some users know their setup works with the speedups enabled, a new parameter is introduced to the driver. Now, a user can specifically enable or disable these features, while the default is what we have today: detect the bridge and decide accordingly. Fixes Bugzilla entry 15014. Simplify and unify the printouts, fix a whitespace issue while we are here. Signed-off-by: Wolfram Sang Tested-by: frod...@gmail.com [li...@dominikbrodowski.net: whitespace fixes] Signed-off-by: Dominik Brodowski And my git log -p drivers/pcmcia/o2micro.h also mentions commit 1ff84890b62b20823b3697a6041bbec1b5280cee Author: Tomas Kovacik Date: Sun Jul 26 22:04:58 2009 +0200 pcmcia: disable prefetch/burst for OZ6933 Problems have been reported [1], so disable prefetch/burst, to be on the safe side. [1] http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02048.html Signed-off-by: Tomáš Kováčik Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman A useful idea would be to kindly ask Tomáš Kováčik (CC'd) about details of his system (4 years later - but hopefully...), specifically lspci -vv -xxx or some such (especially the revision of that controller might be *different*, so perhaps only *some* 6933 remained affected, whereas newer ones of that possibly more modern chipset ID started to get corrected). Or quite likely there's some sufficiently detailed lspci log of that hardware out on the internet somewhere... Note that there's the comment "for some bridges it is at 0x94, for others at 0xD4. it's * ok to write to both registers on all O2 bridges." , yet our 6933 support lines were added *later*, so there's a faint possibility that the compatibility statement actually does not apply to this chipset. And of course there remains the question *why* such slow communication would then cause such severe USB HC communication trouble. There might be some safeguard missing there as well... And kudos to the patch submitters for having supplied such nicely detailed commit logs! (although mentioning the title of URLs probably would have been even better) > Note that this is only a 1.7Ghz Pentium-4-M dinosaur. That means you really don't want to know which kinds of machines I am using ;) (yes, I'm sitting at a CardBus box here, too) ((TI CardBus controller)) Greetings, Andreas Mohr (KA/S) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irq: add quirk for broken interrupt remapping on 55XX chipsets
Hi,
> if ((revision == 0x13) && irq_remapping_enabled) {
> + pr_warn("WARNING WARNING WARNING WARNING WARNING
> WARNING\n"
> + "This system BIOS has enabled interrupt
> remapping\n"
> + "on a chipset that contains an errata making
> that\n"
> + "feature unstable. Please reboot with
> nointremap\n"
> + "added to the kernel command line and contact\n"
> + "your BIOS vendor for an update");
> + }
Forgive me, but ISTR that there's a special BIOS firmware quirk bug annotating
logger warning message mechanism (have I managed to hit all keywords yet? ;)
in the kernel which might be useful in this case.
OK, found something (but I don't think it was the mechanism
that ISTR - perhaps it got modernized?):
include/linux/printk.h:
/*
* FW_BUG
* Add this to a message where you are sure the firmware is buggy or
* behaves
* really stupid or out of spec. Be aware that the responsible BIOS
* developer
* should be able to fix this issue or at least get a concrete idea of
* the
* problem by reading your message without the need of looking at the
* kernel
* code.
*
* Use it for definite and high priority BIOS bugs.
*
* FW_WARN
* Use it for not that clear (e.g. could the kernel messed up things
* already?)
* and medium priority BIOS bugs.
*
* FW_INFO
* Use this one if you want to tell the user or vendor about something
* suspicious, but generally harmless related to the firmware.
*
* Use it for information or very low priority BIOS bugs.
*/
So perhaps it is appropriate to be used here.
HTH,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acerhdf: Fix fan activation with new thermal governor
Hi, On Mon, Mar 04, 2013 at 02:34:10PM +0100, Borislav Petkov wrote: > Pjooiiing! Heh, that was a broken one! Rather well-deserved though - took too much time, been too busy. > Andreas, Peter, can you guys give http://lkml.org/lkml/2012/12/30/47 a run? Will fire up my HDD NOW. About time to get all that stuff going anyway. In need of a new less(?) buggy kernel anyway, since I suspect that stock 2.6.32 to be especially quirky with overly aggressive USB (SSD) resume timing... (keep getting astonishing numbers of -71 timeouts on resume) BTW, thanks very much to Zhang Rui for his timely tackling of the acerhdf matter! Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acerhdf: Fix fan activation with new thermal governor
Hi, On Mon, Mar 04, 2013 at 02:34:10PM +0100, Borislav Petkov wrote: > On Mon, Feb 25, 2013 at 01:16:08PM +0100, Borislav Petkov wrote: > > Ok, doing a short test here proves successful. I'll run it the next days > > too to make sure - it would be nice if people could confirm my test > > results, though. > > > > Tested-by: Borislav Petkov > > Pjooiiing! > > Andreas, Peter, can you guys give http://lkml.org/lkml/2012/12/30/47 a run? I'm now running 3.8 proper with only that patch plus my local beautification-only (really shouldn't matter) acerhdf updates (now properly split ;), and so far fan behaviour seems fine, over various usage conditions. Haven't really stressed it mischievously yet, though. Will do more testing. So this now does not have any of the Schmitt trigger equivalent (?) governor changes that were nicely discussed in this activity - So what do we want to have committed, and what do we not, and most importantly, does it all work fatally precisely correctly? ;) (remember, this is thermal layer, not particularly a place for sloppiness) Thanks, Andreas Mohr -- 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: psmouse synaptics: "hardware appears to be different" bail out
Hi,
On Fri, Jul 20, 2012 at 08:21:45PM +0200, Andreas Mohr wrote:
> Hi,
>
> On Mon, Jul 16, 2012 at 03:07:19PM -0700, Dmitry Torokhov wrote:
> > On Mon, Jul 16, 2012 at 11:44:53PM +0200, Andreas Mohr wrote:
> > > Hi,
> > >
> > > just found the following in dmesg after resume
> > > (currently running -rc7):
> > >
> > > [ 9312.672073] psmouse serio2: synaptics: hardware appears to be
> > > different: id(149271-149271), model(114865-114865), caps(d04771-d04773),
> > > ext(a4-a4).
> > >
> > > Acer Aspire One A110L here.
> > >
> > > Any clever thoughts about this?
> > > Just thought that it might be useful to report it,
> > > especially since the function (in drivers/input/mouse/synaptics.c)
> > > bails out right after this check/message.
> >
> > Hmm, we do not really expect the touchpad change it's caracteristics at
> > all during its lifetime, so no clever ideas here... It looks like a
> > single bit error, but KBC should have signalled parity error in this
> > case...
>
> OK, that might be true in fact.
> I disassembled that device recently (and did quite a bit of work),
> so perhaps the touchpad connection isn't as reliable as I'd want it to
> be...
>
>
> Problem is that now (and some other times, too) S2R resume
> ended up with a dead x.org keyboard (synaptics i.e. mouse pointer
> was still working fine).
> Remote login was ok.
>
> In dmesg, I found:
>
> [ 13.694115] atkbd serio0: Spurious NAK on isa0060/serio0. Some
> program might be trying to access hardware directly.
>
> and then
>
> [ 8278.484469] atkbd serio0: Spurious ACK on isa0060/serio0. Some
> program might be trying to access hardware directly.
>
> which is the one that occurred around the time of the S2R breakage.
> I then triggered a remote pm-suspend,
> and after S2R keyboard WAS FINE AGAIN, with NO dmesg error logged this
> time!!
Hi,
happened again, this time with different but quite ominous messages
("Unable to initialize device."):
[15520.944017] PM: resume of devices complete after 1049.856 msecs
[15520.950597] PM: resume devices took 1.060 seconds
[15520.950787] PM: Finishing wakeup.
[15520.950793] Restarting tasks ... done.
[15520.990705] video LNXVIDEO:00: Restoring backlight state
[15521.107761] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[15521.107774] Bluetooth: BNEP filters: protocol multicast
[15521.287109] Bluetooth: RFCOMM TTY layer initialized
[15521.287158] Bluetooth: RFCOMM socket layer initialized
[15521.287168] Bluetooth: RFCOMM ver 1.11
[15521.347768] atkbd serio0: Spurious ACK on isa0060/serio0. Some
program might be trying to access hardware directly.
[15521.352164] mmc0: new SDHC card at address b368
[15521.357576] mmcblk0: mmc0:b368 14.9 GiB
[15521.370884] mmcblk0: p1
[15521.540130] psmouse serio2: synaptics: Unable to initialize device.
[15522.644250] psmouse serio2: synaptics: Touchpad model: 1, fw: 7.2,
id: 0x1c0b1, caps: 0xd04773/0xa4/0xa
[15522.700396] input: SynPS/2 Synaptics TouchPad as
/devices/platform/i8042/serio2/input/input12
[15523.299199] r8169 :02:00.0: eth1: link down
Identical symptoms: touchpad mighty fine, keyboard DEAD. Remote pm-suspend
fixed everything.
This time this occurred at the first suspend after initial kernel bootup
(not sure about previous incidents).
Log of the subsequent second resume that managed to repair the state:
[16584.645148] PM: resume of devices complete after 1052.387 msecs
[16584.648803] PM: resume devices took 1.050 seconds
[16584.648996] PM: Finishing wakeup.
[16584.649002] Restarting tasks ... done.
[16584.684401] video LNXVIDEO:00: Restoring backlight state
[16585.041476] mmc0: new SDHC card at address b368
[16585.055439] mmcblk0: mmc0:b368 14.9 GiB
[16585.058917] mmcblk0: p1
[16585.330295] r8169 :02:00.0: eth1: link up
Note the large amount of *missing* input device messages (all due to error
condition?) in the non-fatal case.
"Some program might be trying to access hardware directly." - mayhaps
on resume we've got some BIOS DMI handlers fumbling things
that they shouldn't fumble?
Still running -rc7, though (time for upgrade treadmill, I know ;).
Thanks,
Andreas Mohr
--
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/
[semi-solved] Re: [sdhci] mmc0: unrecognised SCR structure version 1
Hi, On Sat, Sep 29, 2007 at 10:35:16AM +0200, Pierre Ossman wrote: > On Sat, 29 Sep 2007 05:42:37 +0200 (CEST) > Adam Wysocki <[EMAIL PROTECTED]> wrote: > > > [CCd to possibly interested Pierre Ossman and Rodolfo Giometti] > > > > Hi there, > > > > First, sorry for my poor english - I am not a native. > > > > I know there have been a thread about this problem few months ago, > > but as far as I see it did not led to any results: > > http://groups.google.com/group/linux.kernel/browse_thread/thread/19116cafe8a20b5/4a28c3b15bb999df > > > > I have the same problem, as described there, with Kingston 2GB SD > > card. My card reader is embedded into Fujitsu-Siemens AMILO Pro V3505 > > notebook and Linux sees it as: > > > > If it's just this card, then I would have to conclude that it is indeed > broken. You'd have to return it to the store and get a new one. My Toshiba SD-512-T card (Toshiba-specific specs are available as TOSHIBA_SD_Card_Specification.pdf) shows the same "SCR structure version 1" error message with 2.6.24 on a Motorola E680 (PXAMCI), whereas on 2.6.21 it did _NOT_ have it (and all SCR values there are a 1:1 match with the values listed in the spec .pdf!). For me at least it turned out that while on 2.6.21, raw_scr had 0x00a5 0x10011602 on 2.6.24 raw_scr had 0x10011602 0x IOW, the whole thing is simply shifted by one unsigned int, rendering any SCR interpretation fatally wrong (which, I believe, could be a _permanent_ error in the SD stack itself which randomly - depending on the exact bit content of a card's SCR dump - causes the SCR version check to trigger for various cards). Is this unsigned int shifting due to a transfer setup issue in the highlevel SD stack or do you think it is due to a setup issue in the lower-level pxamci driver in my case? If so, what setting could have distorted it? Weak voltage settings are not to blame, I believe (removed some configs to increase a bit from minimum supported voltage). If you don't have any specific ideas yet, any hints on how to proceed with tracking this down? I'd advise at least adding dumping the raw_scr values in the SCR version error to be able to track such error postings better in the future. I'm now giving up on tracking this down myself (I'll just bail the check for now to have it boot properly) since originally I had more productive things in mind ;) (note that disabling the check on 2.6.24 makes the card boot ok up to a full mobile desktop) Thanks, Andreas Mohr -- 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: psmouse synaptics: "hardware appears to be different" bail out
Hi, On Mon, Jul 16, 2012 at 03:07:19PM -0700, Dmitry Torokhov wrote: > On Mon, Jul 16, 2012 at 11:44:53PM +0200, Andreas Mohr wrote: > > Hi, > > > > just found the following in dmesg after resume > > (currently running -rc7): > > > > [ 9312.672073] psmouse serio2: synaptics: hardware appears to be > > different: id(149271-149271), model(114865-114865), caps(d04771-d04773), > > ext(a4-a4). > > > > Acer Aspire One A110L here. > > > > Any clever thoughts about this? > > Just thought that it might be useful to report it, > > especially since the function (in drivers/input/mouse/synaptics.c) > > bails out right after this check/message. > > Hmm, we do not really expect the touchpad change it's caracteristics at > all during its lifetime, so no clever ideas here... It looks like a > single bit error, but KBC should have signalled parity error in this > case... OK, that might be true in fact. I disassembled that device recently (and did quite a bit of work), so perhaps the touchpad connection isn't as reliable as I'd want it to be... Problem is that now (and some other times, too) S2R resume ended up with a dead x.org keyboard (synaptics i.e. mouse pointer was still working fine). Remote login was ok. In dmesg, I found: [ 13.694115] atkbd serio0: Spurious NAK on isa0060/serio0. Some program might be trying to access hardware directly. and then [ 8278.484469] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly. which is the one that occurred around the time of the S2R breakage. I then triggered a remote pm-suspend, and after S2R keyboard WAS FINE AGAIN, with NO dmesg error logged this time!! Don't tell me we've got a "short intermittent hardware failure on resume leads to final hardware unusability" issue here ;-) Anything to gather debug information when it happens again? Perhaps some event helper tools or some such? Xorg.0.log does not show any keyboard / input(keyboard) lines in the whole interesting time range (only a ton of synaptics messages). OTOH I remember some very recent work on x.org synaptics driver resume behaviour, maybe that was done to fix such keyboard cases... Thanks, Andreas Mohr -- 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/
[REGRESSION] [nailed] USB boot failure: USB: EHCI: make ehci-pci a separate driver
Hi guys (*wink*),
On Tue, Feb 12, 2013 at 08:16:17AM -0800, Greg KH wrote:
> On Tue, Feb 12, 2013 at 05:07:27PM +0100, Andreas Mohr wrote:
> > On Sun, Feb 10, 2013 at 03:05:54PM +0100, Andreas Mohr wrote:
> > > Regression sorta confirmed now. -rc3 with a fully suitable .config does
> > > not boot either. Will start bisection. Will take ages.
> >
> > Down to 91 commits (all in USB land!), around 7 steps left.
> > Pretty certain of a valid regression now. Things did properly do the
> > good/good/bad/bad/good... dance.
> >
> > Oh so lovely if you're constrained to >= 5 hour build times,
>
> You do know about 'make localmodconfig', right? That should cut your
> build time down a large amount.
[I didn't]
Never managed to actually get to run localmodconfig, since I never
got to a bad build again (for properly confirming a reduced-set bad
vs. full-build bad) before finally hitting a subsequent bad one
with very limited incremental build efforts anyway (module headers only), doh...
And the winner is... ("oh no!")
# git bisect good
adfa79d1c06a32650332930ca4c488ca570b3407 is the first bad commit
commit adfa79d1c06a32650332930ca4c488ca570b3407
Author: Alan Stern
Date: Thu Nov 1 11:13:04 2012 -0400
USB: EHCI: make ehci-pci a separate driver
This patch (as1625) splits the PCI portion of ehci-hcd out into its
own separate driver module, called ehci-pci. Consistently with the
current practice, the decision whether to build this module is not
user-configurable. If EHCI and PCI are enabled then the module will
be built, always.
Signed-off-by: Alan Stern
CC: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman
:04 04 1b7bf7a030df56852a48bf243862f70d5522e098
ad780e9c56d6647de5db9a5e87256ae2a79d4041 M drivers
# git bisect log
git bisect start
# bad: [9931faca02c604c22335f5a935a501bb2ace6e20] Linux 3.8-rc3
git bisect bad 9931faca02c604c22335f5a935a501bb2ace6e20
# good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# bad: [db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070] Merge tag 'dt' of
# git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070
# bad: [fef3ff2eb777e76cfa5ae67591982d902c17139c] Merge branch 'for-3.8'
# of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu
git bisect bad fef3ff2eb777e76cfa5ae67591982d902c17139c
# good: [7bcb57cde66c19df378f3468ea342166a8a4504d] Merge tag
# 'iio-for-3.8f' of
# git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into
# staging-next
git bisect good 7bcb57cde66c19df378f3468ea342166a8a4504d
# good: [c6bd5bcc4983f1a2d2f87a3769bf309482ee8c04] Merge tag
# 'tty-3.8-rc1' of
# git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect good c6bd5bcc4983f1a2d2f87a3769bf309482ee8c04
# bad: [aefb058b0c27dafb15072406fbfd92d2ac2c8790] Merge branch
# 'irq-core-for-linus' of
# git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad aefb058b0c27dafb15072406fbfd92d2ac2c8790
# bad: [70847780dca19f3707d9fa433f68edf8cbaf91f2] usb: host: tegra:
# remove pointless NULL check in tegra_ehci_remove()
git bisect bad 70847780dca19f3707d9fa433f68edf8cbaf91f2
# bad: [09f6ffde2ecef4cc4e2a5edaa303210cabd96f57] USB: EHCI: fix build
# error by making ChipIdea host a normal EHCI driver
git bisect bad 09f6ffde2ecef4cc4e2a5edaa303210cabd96f57
# good: [e1deb56cb775ab953bc5245feaf1f43269409139] usb: ehci-s5p: use
# clk_prepare_enable and clk_disable_unprepare
git bisect good e1deb56cb775ab953bc5245feaf1f43269409139
# good: [86effe5980e25f4fac10a0f22938c2fcd4a32690] USB: fix build with
# XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled
git bisect good 86effe5980e25f4fac10a0f22938c2fcd4a32690
# good: [571e41214e988bc38c99d804e6d8e1ea1d016342] USB: remove iteration
# limit in hub_tt_work()
git bisect good 571e41214e988bc38c99d804e6d8e1ea1d016342
# good: [7c83b4483606f5fe14127249336ac53ef177a63a] USB: option: idVendor
# and idProduct are __le16
git bisect good 7c83b4483606f5fe14127249336ac53ef177a63a
# bad: [99f91934a907df31ba878dfdd090002049dc476a] USB: EHCI: make
# ehci-platform a separate driver
git bisect bad 99f91934a907df31ba878dfdd090002049dc476a
# bad: [adfa79d1c06a32650332930ca4c488ca570b3407] USB: EHCI: make
# ehci-pci a separate driver
git bisect bad adfa79d1c06a32650332930ca4c488ca570b3407
# good: [3e0232039967d7a1a06c013d097458b4d5892af1] USB: EHCI: prepare to
# make ehci-hcd a library module
git bisect good 3e0232039967d7a1a06c013d097458b4d5892af1
History: Acer Aspire One netbook, boot from USB SSD failed to populate
/dev/disk/by-uuid/ properly, due to enumerating *parts* of the USB
device tree only, as seen
Re: [REGRESSION] [nailed] USB boot failure: USB: EHCI: make ehci-pci a separate driver
Hi, On Wed, Feb 13, 2013 at 07:44:36AM +0100, Andreas Mohr wrote: > So, what to do? I'm now going to do some experimentation with git revert > on some revision, and I'm trying to establish the USB port dependency > (BIOS-owned handoff root hub invisible!?, as discussed in initial mail). After some bingo moment, seems the solution is easier than expected: andi@andinet:~$ ls /tmp/initrd_extracted/lib/modules/3.7.0-rc5+/kernel/drivers/usb/host/ ehci-hcd.ko ohci-hcd.ko uhci-hcd.ko xhci-hcd.ko andi@andinet:~$ ls /lib/modules/3.7.0-rc5+/kernel/drivers/usb/host/ ehci-hcd.ko isp116x-hcd.ko sl811_cs.ko uhci-hcd.ko ehci-pci.ko ohci-hcd.ko sl811-hcd.ko whci hwa-hc.kor8a66597-hcd.ko u132-hcd.ko xhci-hcd.ko So it's probably only that the initrd simply fails to ship the ehci-pci.ko module (I could verify this by extending initrd content, BTW). Now the question would be: are modules listed in a static list on initramfs package/config side, or does the kernel fail to signal the list of required modules properly? (e.g. did some config-side files fail to get upgraded for this dependency??) So maybe it's not a "regression" per se, but it's at least a grave usability issue on kernel upgrade which should be handled as benignly as possible (i.e., without any disruption). Thanks, Andreas Mohr -- 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] [nailed] USB boot failure: USB: EHCI: make ehci-pci a separate driver
[CC initramfs-tools] On Wed, Feb 13, 2013 at 08:16:28AM +0100, Andreas Mohr wrote: > Hi, > > On Wed, Feb 13, 2013 at 07:44:36AM +0100, Andreas Mohr wrote: > > So, what to do? I'm now going to do some experimentation with git revert > > on some revision, and I'm trying to establish the USB port dependency > > (BIOS-owned handoff root hub invisible!?, as discussed in initial mail). > > > After some bingo moment, seems the solution is easier than expected: > > andi@andinet:~$ ls > /tmp/initrd_extracted/lib/modules/3.7.0-rc5+/kernel/drivers/usb/host/ > ehci-hcd.ko ohci-hcd.ko uhci-hcd.ko xhci-hcd.ko > andi@andinet:~$ ls /lib/modules/3.7.0-rc5+/kernel/drivers/usb/host/ > ehci-hcd.ko isp116x-hcd.ko sl811_cs.ko uhci-hcd.ko > ehci-pci.ko ohci-hcd.ko sl811-hcd.ko whci > hwa-hc.kor8a66597-hcd.ko u132-hcd.ko xhci-hcd.ko > > So it's probably only that the initrd simply fails to ship > the ehci-pci.ko module (I could verify this by extending initrd content, BTW). > Now the question would be: > are modules listed in a static list on initramfs package/config side, > or does the kernel fail to signal the list of required modules properly? > (e.g. did some config-side files fail to get upgraded for this dependency??) > > > So maybe it's not a "regression" per se, but it's at least a grave > usability issue on kernel upgrade which should be handled as benignly as > possible (i.e., without any disruption). OK, initramfs-tools hook-functions file contains (even in git master): for arg in "$@" ; do case "$arg" in base) modules="$modules ehci-hcd ohci-hcd uhci-hcd usbhid" modules="$modules xhci xhci-hcd" modules="$modules hid-apple hid-cherry hid-generic" modules="$modules hid-logitech hid-logitech-dj" modules="$modules hid-microsoft hid-sunplus" modules="$modules btrfs ext2 ext3 ext4 ext4dev " modules="$modules isofs jfs nfs reiserfs udf xfs" modules="$modules af_packet atkbd i8042 virtio_pci" ;; So it seems it actually *is* the user side (initramfs-tools) which has to maintain knowledge of all dependencies in a painfully maintained hard-coded list, and it seems this change is now making it croak, due to not knowing about the newly split extra ehci-pci.ko. Questions: - is this mechanism how one would want things to be? (is there a way to cleanly provide the accurately updated list from the kernel side? Or is there a scripted mechanism to at least extract all required *dependee* modules from the list of the ones that we already know of? That would have saved our a** here...) - was this module change properly communicated sufficiently in advance, to (all/most of) some affected parties? If not, might want to do better next time if that's possible... - should ehci-pci be added to the literal list now (and does this work properly on kernels which don't have it??), to get back to a working state ASAP? Thanks, Andreas Mohr -- 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] [nailed] USB boot failure: USB: EHCI: make ehci-pci a separate driver
Indeed, adding ehci_pci to /etc/initramfs-tools/modules and running update-initramfs -u -k 3.7.0-rc5+ to get /boot/initrd.img-3.7.0-rc5+ of the formerly broken -rc5+ build corrected manages to fix boot. On Wed, Feb 13, 2013 at 08:44:09AM +0100, Andreas Mohr wrote: > (is there a way to cleanly provide the accurately updated list > from the kernel side? Or is there a scripted mechanism to at least extract > all required *dependee* modules from the list of the ones that we > already know of? That would have saved our a** here...) Wouldn't have... ehci-pci is the new top-level depender on ehci-hcd, not the other way around. Unfortunately such a change is even more insidious since one cannot pick up the change in an automated manner (via dependency inspection). A more automated yet KISS solution for initramfs dependency stuff would be desireable if perhaps unfeasible. Andreas Mohr -- 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] [nailed] USB boot failure: USB: EHCI: make ehci-pci a separate driver
[not sure about CCs - I readded both initramfs-tools and lkml] > I think you actually want both: ehci-pci and ehci-platform (tho' perhaps > the module deps mean only the -pci one is needed) Err, yeah, that's probably more precise. > Either way I already posted a patch about this a while back: > See: "[PATCH 6/6] kernel-modules: Add ehci support for kernel 3.8+" OK, I've seen it, but: which file does it touch?? That's a complete mystery to me (the initramfs-tools git checkout here does not contain that path). > (admittedly perhaps that should have been 3.7 rather than 3.8)! Hmm, the patch was introduced in early moments from 3.7 prior to 3.8-rc1. Thus one could say that the non-covered window is only a part of the small 3.8-rc1 step which is used by devel people only. OTOH to retain the very important development property of properly working regression bisects over all versions (of regressions *other* than this USB boot effect, that is), even that smallish window ought to be fully covered. If it thus is decided to be a sizeable versioning issue, then it really should be downgraded to 3.7 very soon, in order to prevent a support window coverage issue. Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI / ACPI: Report _OSC control mask returned on failure to get control
Hi, to provide an example case, on Aspire One AOA110 v0.3310, 3.8-rc7 prints: [0.515599] ACPI Error: [CAPB] Namespace lookup failure, AE_ALREADY_EXISTS (2 0121018/dsfield-211) [0.515629] ACPI Error: Method parse/execution failed [\_SB_.PCI0._OSC] (Node f5449680), AE_ALREADY_EXISTS (20121018/psparse-537) [0.515672] ACPI: Marking method _OSC as Serialized because of AE_ALREADY_EXISTS error [0.516081] ACPI Error: [CAPB] Namespace lookup failure, AE_ALREADY_EXISTS (20121018/dsfield-211) [0.516107] ACPI Error: Method parse/execution failed [\_SB_.PCI0._OSC] (Node f5449680), AE_ALREADY_EXISTS (20121018/psparse-537) [0.516168] pci_root PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM [0.516179] pci_root PNP0A08:00: Unable to request _OSC control (_OSC support mask: 0x08) HTH, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI / ACPI: Report _OSC control mask returned on failure to get control
Hi, On Thu, Feb 14, 2013 at 01:07:02PM +0100, Rafael J. Wysocki wrote: > Unfortunately, it doesn't, because I've lost track of the whole thread in the > meantime. Care to give a pointer? In other words, you'd like to tell me rather straight that I should stop doing such nonsense as replying to a very old patch posting with some (questionably?) useful info related to that case? And I here I was thinking that linking things together according to their relations/relevancy would be a good thing :) Your oldish patch can be seen at https://lkml.org/lkml/2011/4/29/406 (or perhaps I should at least specify the URL reference when replying to older activity) Sorry & Thanks, Andreas Mohr -- 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/
[ASAP] thermal_sys.c NULL ptr deref patch likely incomplete
Hi,
I just had a
# cat /sys/class/thermal/thermal_zone0/policy
(null)
When looking at the code (on my -rc7), I saw:
drivers/thermal/thermal_sys.c
static ssize_t
policy_show(struct device *dev, struct device_attribute *devattr, char
*buf)
{
struct thermal_zone_device *tz = to_thermal_zone(dev);
return sprintf(buf, "%s\n", tz->governor->name);
}
(not sure though why I manage to get a "(null)" rather than a crash
due to the dereferencing prior to output - possibly since I do have a
valid governor allocated yet then only its name field is null?)
Seems we are missing a critical (and -rc-relevant) patch here
(and perhaps at other locations in this file, too, given that
this one was missed last time?).
Currently trying to get acerhdf operation into a working state
(and having some trouble with it - didn't know that I probably need some
governor setup which seems to have just been available on my last setup,
or so)
Thanks,
Andreas Mohr
--
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/
thermal governor: does it actually work??
For me after having loaded acerhdf the fan never stops (with kernelmode active), despite staying safely below trip point (acerhdf_set_cur_state() actually never gets called). And AFAIR in a 3.2.0 kernel acerhdf fan operation seemed to just work (i.e., no fan for low temps, from the beginning). Needless to say 3.2.0 didn't even feature all the modern thermal governor crapyard yet ;) (ok, well, it's more complex but it's also a very nice environment capability) 3.8-rc7: CONFIG_ACPI_THERMAL=m CONFIG_THERMAL=m CONFIG_THERMAL_HWMON=y CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y # CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set # CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set CONFIG_FAIR_SHARE=y CONFIG_STEP_WISE=y # CONFIG_USER_SPACE is not set # CONFIG_CPU_THERMAL is not set Terminology in this area seems to be quite a bit off, too, at several docs places, at least according to my understanding: e.g. drivers/thermal/step_wise.c has the following comment: /** * step_wise_throttle - throttles devices associated with the given zone * @tz - thermal_zone_device * @trip - the trip point * @trip_type - type of the trip point * * Throttling Logic: This uses the trend of the thermal zone to * throttle. * If the thermal zone is 'heating up' this throttles all the cooling * devices associated with the zone and its particular trip point, by * one * step. If the zone is 'cooling down' it brings back the performance of * the devices by one step. if ... heating up ... throttles ... Sorry, but at least for P4 clockmod stuff (or some such), throttle states (P1...P8 IIRC) meant that the CPU operation was *reduced*, i.e. with pause intervals. And the translation of throttle clearly says that it does go that way and not the other way... (yes, you managed to confuse me that much that I even had to look up things to verify) ... cooling down ... brings back ... This should certainly be worded "reduces" or some such. So, any idea why I'm missing callbacks in acerhdf (if that is what I'm supposed to expect to happen)? Kernel bug, .config mistake, missing/wrong user-side setup? Needless to say if kernel bug this ought to be fixed pre-3.8 ideally. Thanks, Andreas Mohr -- 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: thermal governor: does it actually work??
Hi, On Fri, Feb 15, 2013 at 09:47:07AM +, Zhang, Rui wrote: > Please attach the output of > "grep . /sys/class/thermal/thermal_zone*/cdev*/*"? # grep . /sys/class/thermal/thermal_zone*/cdev*/* /sys/class/thermal/thermal_zone0/cdev0/cur_state:1 /sys/class/thermal/thermal_zone0/cdev0/max_state:1 grep: /sys/class/thermal/thermal_zone0/cdev0/power: Is a directory grep: /sys/class/thermal/thermal_zone0/cdev0/subsystem: Is a directory /sys/class/thermal/thermal_zone0/cdev0/type:acerhdf-fan > The question is that if we can also call it "throttle" when reducing the > device performance to generate less heat. I won't continue to elaborate on this separate issue now, given that my time currently is very limited ;) Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mcs7830: Fix link state detection
Hi,
On Thu, Oct 11, 2012 at 12:33:28PM +0200, Ondrej Zary wrote:
> u8 *buf = urb->transfer_buffer;
> bool link;
> + struct mcs7830_data *data = mcs7830_get_data(dev);
>
> if (urb->actual_length < 16)
> return;
Alternatively could do *data = NULL; and then actually assign after the
conditional.
But since the conditional most likely is coldpath
I think your chosen implementation is best.
>
> link = !(buf[1] & 0x20);
> if (netif_carrier_ok(dev->net) != link) {
I usually like to introduce helper bools to clearly express the intention
behind things (source code should be readable like a book, yet it all
too often is everything but...).
I.e.
bool link_state_change_detected = (netif_carrier_ok..);
if (bool)
Might be an idea here, too.
The logic behind your counter implementation seems solid to me
(short explanatory comment "track link state several times, to guard against
transient erroneous link state of (some versions of?) this chip"
might have been useful though).
Thank you very much for your patch!
Andreas Mohr
--
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: Linux 3.8-rc1 - another regression on USB :-(
Hi, > Greg, Linus, > It sounds insane, but after banging on the issue I have found out that > USB problem is caused (also in vanilla kernel) with a config change: > USB-all built as modules - bad USB > USB core built in, UHCI/EHCI modules - semi functional - but 1Mb/s > transfer > USB core and UHCI EHCI built-in - bingo - no issues. > > Could anybody duplicate that, or is it somehow my setup??? Since there was no additional reply here (needed) so far, some of my (questionably relevant?) thoughts on this: There's of course the EHCI vs. UHCI(/OHCI) duality (EHCI host controller responsible for high speed transfers, the other for 1.1 full speed, both serving the same port connectors). So if the coordination between the two is a problem, you might end up with merely full speed on a 2.0 port. And with drivers builtin vs. module, the init sequence/timing might possibly be affected - right? Perhaps this got worsened by semi-recent driver init kernel changes? (AFAIR the kernel was changed to init more things in parallel, for faster bootup). So maybe that affected EHCI vs. UHCI coordination timing. (taking many stabs in the dark here...) I seem to have USB issues as well; for some storage devices I cannot gain high speed currently, while e.g. for USB sticks that works - and of course prior to disabling the BIOS's limit-to-1.1 setting (doh! oh my...) that was very understandable, but AFAIK it's still not reliable (maybe it's some of my local host controller troubleshooting commits... need to git revert them). Due to my woes originally being BIOS-originated I cannot provide any hard evidence about any 3.7.x vs. 3.8.x breakage timeframe. I noticed that I had PSU issues - the 5V rail was dangerously low; resoldering/cleaning the PSU helped. In your case the USB disconnects might hint at that as well - I'd recommend installing an lm-sensors configuration (or check at BIOS health page) like I did. I'm in the process of compiling a small but hopefully helpful USB troubleshooting document (voltage, EMI, ...). I'm usually more or less current (currently on -rc2 plus local commits). Andreas Mohr -- 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] irq_work changes for 3.9
Hi, > These three patches are general fixes for irq work. The two first > patches fix tight races on global irq work claiming that prevent the irq work > subsystem from dropping a work enqueuing attempt because it thinks it's > already pending while it may be already executing or executed. Would that one happen to be one that would fix my system dropping dead on sound output (looping the existing buffer ad infinitum) every couple idle minutes when using my sound card's PulseAudio IRQ-less playback patch (to-be-submitted), and which seems to have started (or got quite a bit worse so as to let me notice?) once I added my "quirks: enable APIC De-Assert Message bit for VIA 8235, too." (to-be-submitted) commit? (which reduces IRQs from duplicate to single - thereby probably reducing the opportunities for the system to notice that work is pending) Of course a lone kick to the mouse always fixes it... (-rc2 here) Hell yeah that does sound like a potential candidate to me. Andreas Mohr -- 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] irq_work changes for 3.9
Hi, [trimmed recipient list] On Wed, Jan 16, 2013 at 11:12:09PM +0100, Frederic Weisbecker wrote: > 2013/1/16 Andreas Mohr : > > Hell yeah that does sound like a potential candidate to me. > > > > Andreas Mohr > > I doubt it. I don't see a sound driver using struct irq_work: > > $git grep -F "struct irq_work" drivers/ sound/ Even a more liberal search comes up similar. I didn't know that irq_work is a somewhat more specific mechanism, thank you for the clarification! Leaves me wondering what actually could be responsible for this... (perhaps even a userland bug i.e. PA buffer replenishing issues) Oh well... Andreas Mohr -- 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: forcedeth: MAC-address reversed on resume from suspend
Hi, On Fri, Jan 04, 2008 at 04:43:57AM +0100, Björn Steinbrink wrote: > On 2008.01.03 01:42:09 +0200, Adrian Bunk wrote: > > [ original bug report: http://lkml.org/lkml/2008/1/2/253 ] > > > > On Wed, Jan 02, 2008 at 10:48:43PM +0100, Andreas Mohr wrote: > > > The nv_probe() function then nicely obeys this flag by reversing the > > > address if needed, _however_ there's another function, > > > nv_copy_mac_to_hw(), which does _NOT_ obey it and simply copies the > > > _raw_ netdev dev_addr to the card register (NvRegMacAddrA etc.). > > nv_copy_mac_to_hw() is called from nv_probe() _after_ the MAC address > has been fixed, and from nv_set_mac_address() which is supposed to get a > correct MAC address anyway. So I don't see any problem there. /* set permanent address to be correct aswell */ ... orig_mac fumbling ... Why, then, does this driver do such a nice hack as: /* special op: write back the misordered MAC address - otherwise * the next nv_probe would see a wrong address. */ writel(np->orig_mac[0], base + NvRegMacAddrA); writel(np->orig_mac[1], base + NvRegMacAddrB); I really don't see why this driver needs to do these things in such a messy way. One thing is for certain: netdev->dev_addr is always in operating system order, and order should always be handled properly when copying to/from hardware. Such a driver needs exactly *one* central helper method to reverse an input MAC address in 6 bytes u8 format (which could arguably be added to include/linux/etherdevice.h even, since a wee bit too many devices seem to be having trouble with wrongly ordered MAC addresses). Then it needs exactly *one* function for I/O register access to read a MAC address from a device and exactly *one* function to write it back (both doing raw, unsorted format transfers only, and possibly as inline function). And then it needs these card I/O functions wrapped into two functions which interface with driver- and OS-related MAC variables (struct variables ALWAYS stored in usual system order, NOT H/W order!!) which optionally reverse the address (if needed for a particular card). And then there will never be any confusion about any MAC address format anywhere any more, right? I really don't mean to sound cranky, but this driver did ask for trouble, and lots of it ;) Thank you for your reply, and especially thank you for this very fast patch! I might even have enough time this weekend to work on this... Andreas Mohr -- 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: forcedeth: MAC-address reversed on resume from suspend
On Fri, Jan 04, 2008 at 11:17:40AM +0100, Björn Steinbrink wrote: > On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote: > > And then it needs these card I/O functions wrapped into two functions which > > interface with driver- and OS-related MAC variables > > (struct variables ALWAYS stored in usual system order, NOT H/W order!!) > > which optionally reverse the address (if needed for a particular card). > > Hu? The MAC address is only ever reversed when the card is not in use, > why the hell would you want to reverse anything when the rest of the OS > is involved? This whole reversing stuff is purely before and after the > card is actually used. It's not that you need to reverse the address to > communicate with the card, it's just initially wrong on the card. Huhrmm? OK, let me ask this then: So what you're saying is that the address is only initially wrong (e.g. due to card EEPROM content somehow initializing the registers in wrong order on power-on), it's not _always_ supposed to be stored in wrong order during operation. IOW, the default card state after power-on is _unusable_ (due to invalidly ordered MAC address) and has to be _corrected_ by the driver, _initially_ only? OTOH I know that at least acx100 has a _permanently_ wrong-ordered MAC address setup, i.e. it's required to have it in "wrong" order _during operation_. And I wouldn't be surprised to see several examples of other hardware having a permanently wrongly-ordered address requirement, given the amount of MAC reversal in Linux drivers. Couldn't it be by chance that it's _believed_ to be reversed-on-power-on only, whereas those cards should _actually_ have it reversed-during-lifetime instead? Such a misunderstanding might explain a lot of trouble... Obviously I was expecting the latter case, which my code layout proposal was supposed to support in a clean way. > > And then there will never be any confusion about any MAC address format > > anywhere any more, right? > > At probing time, you'll have to know whether the address you read from > the hardware is reversed or not. Unless you write it back in reversed > order when you release the card, you need a flag that at least survives > until nv_probe is called the next time. kexec does not write it back, so > you do need such a flag. But the flag apparently doesn't survive a > suspend/resume cycle, so you need to write back the reversed address > then. But the flag will survive a rmmod + modprobe cycle, so you need to > reset it when writing back the reversed address. If it's indeed reversed-on-power-on only, then one probably cannot do much about it, thus I'd give up and simply check the MAC address for validity (should be very easy to check for a simple reversal by checking for the manufacturer-specific fingerprint in reverse order). Keeping _any_ sort of state to record the fact that it used to be reversed or now is reversed is futile (or rather: catastrophic) given the complexity of suspend / virtualisation or whichever other nice operations Linux may invent in the future ;) > Well, let's see if my analysis was correct and the patch works, first. I > saw the forcedeth code before, but kexec and suspend is totally new to > me and I just made some assumptions based on the reported behaviour and > the commit messages... ;-) You most likely did more analysis than me, I just said "this very obviously must be the problem" and replied ;) Andreas Mohr -- 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.24-rc4-git5: Reported regressions from 2.6.23
Hi, On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote: > > Does this report now win me the lucky draw, pretty please? ;) > > nah, you have to cc the acpi guys to get a prize ;) Thought so shortly, but missed it. > Andreas, please do separately report that WOL problem too.. Local setup issue only, at least this one *isn't* a 2.6.24-rc regression. ;) > Our list just reached 30. Oh, so this is in fact a separate issue? Wasn't sure, couldn't do enough analysis of similar cases. Will test any (already submitted!) suggestions ASAP. Andreas Mohr -- 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.24-rc4-git5: Reported regressions from 2.6.23
e supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
AGP is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
Handle 0x0001, DMI type 1, 25 bytes
System Information
Manufacturer: VIA Technologies, Inc.
Product Name: VT8367-8235
Version:
Serial Number:
UUID: Not Present
Wake-up Type: Power Switch
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer:
Product Name: VT8367-8235
Version:
Serial Number:
Handle 0x0003, DMI type 3, 13 bytes
Chassis Information
Manufacturer:
Type: Desktop
Lock: Not Present
Version:
Serial Number:
Asset Tag:
Boot-up State: Unknown
Power Supply State: Unknown
Thermal State: Unknown
Security Status: Unknown
Handle 0x0004, DMI type 4, 32 bytes
Processor Information
Socket Designation: Socket A
Type: Central Processor
Family: Duron
Manufacturer: AMD
ID: 81 06 00 00 FF FB 83 03
Signature: Family 6, Model 8, Stepping 1
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
MMX (MMX technology supported)
FXSR (Fast floating-point save and restore)
SSE (Streaming SIMD extensions)
Version: AMD K7 processor
Voltage: 3.3 V
External Clock: 133 MHz
Max Speed: 1500 MHz
Current Speed: 1200 MHz
Status: Populated, Enabled
Upgrade: ZIF Socket
L1 Cache Handle: 0x000A
L2 Cache Handle: 0x000B
L3 Cache Handle: No L3 Cache
Handle 0x0005, DMI type 5, 24 bytes
Memory Controller Information
Error Detecting Method: None
Error Correcting Capabilities:
None
Supported Interleave: One-way Interleave
Current Interleave: Four-way Interleave
Maximum Memory Module Size: 32 MB
Maximum Total Memory Size: 128 MB
Supported Speeds:
70 ns
60 ns
Supported Memory Types:
Standard
EDO
Memory Module Voltage: 5.0 V
Associated Memory Slots: 4
0x0006
0x0007
0x0008
0x0009
Enabled Error Correcting Capabilities: None
.
.
.
# hdparm -i /dev/sda
/dev/sda:
Model=WDC WD1200JB-00CRA1 , FwRev=17.07W17,
SerialNo=WD-WCA8C4285629
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5
* signifies the current active mode
Athlon on EPOX 8K5A2+ board.
Again, 2.6.23 and 2.6.24-rc1 work, yet 2.6.24 -rc2, -rc3 and -rc4 FAIL.
Probably won't be able to do any reporting over the weekend (WOL is
inoperable ATM for some weird reason), let me know what you need.
Took too much time to gather this report already anyway ;)
Thanks,
Andreas Mohr
--
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.24-rc4-git5: Reported regressions from 2.6.23
Hi, On Mon, Dec 10, 2007 at 12:46:57AM +0900, Tejun Heo wrote: > Please post full kernel boot log and the result of 'lspci -nn'. Done, on #9530. Will try some of the promising patches/suggestions now, hopefully this will show me what's up. Will add further results there. Andreas Mohr -- 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.24-rc4-git5: Reported regressions from 2.6.23
Hi,
[ACPI _GTM suspend issue sorta fixed, read below]
On Sat, Dec 08, 2007 at 12:24:16PM -0600, Robert Hancock wrote:
> Matthew Garrett wrote:
>> On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote:
>>> On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote:
>>>> ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0) is
>>>> beyond end of object [20070126]
>>>> ACPI Error (psparse-0537): Method parse/execution failed
>>>> [\_SB_.PCI0.IDE0.GTF_] (Node c180b990), AE_AML_PACKAGE_LIMIT
>>>> ACPI Error (psparse-0537): Method parse/execution failed
>>>> [\_SB_.PCI0.IDE0.CHN0.DRV1._GTF] (Node c180b888), AE_AML_PACKAGE_LIMIT
>>>> ata1.01: _GTF evaluation failed (AE 0x300d)
>>
>> 037f6bb79f753c014bc84bca0de9bf98bb5ab169 ought to have fixed this?
>>
>
> I should think it should have.
Yup, the _GTF problem is certainly fixed, but this is a dead-end
since I showed the -rc1 vs. -rc2 behaviour, whereas I still have
failing suspend in -rc4 with this patch confirmed to be applied
(source does contain the changes) and confirmed to apparently be working
(no errors in dmesg any more).
IOW, what I'm concerned about is not a _GTF error on boot any more,
but a seemingly fatally handled _GTM error on suspend.
...OK, dug some more into this, and now I managed to get it to work,
and it was indeed _GTM which broke my whole suspend:
Since _GTM is failing on me (and the point is, it's failing
catastrophically, not "normally"!), ata_acpi_on_suspend()
calling ata_acpi_gtm() fails with -EINVAL instead of -ENOENT,
however ata_acpi_on_suspend() has the following correction only:
if (rc == -ENOENT)
rc = 0;
to make sure a suspend doesn't get aborted (fatal error) when
_GTM is simply empty.
Changing this into
if ((rc == -ENOENT) || (rc == -EINVAL))
rc = 0;
to additionally account for _invalid_ _GTM execution makes my suspend
(and resume!) work again on -rc4.
Now the question is whether this error code correction is ok, or whether a
catastrophically failing _GTM should have been truly registered on boot
already (where it does gtm to fetch cable timings) to subsequently avoid
doing any ATA ACPI things on suspend at all.
And the second, possibly much more lucrative, question would be
whether we're actually doing something wrong with our ACPI _GTM execution
which triggers the AE_AML_PACKAGE_LIMIT problem.
This might help here, perhaps (relevant snippets of AML dump):
Device (CHN0)
{
Name (_ADR, 0x00)
Method (_GTM, 0, NotSerialized)
{
Return (GTM (PMPT, PMUE, PMUT, PSPT, PSUE, PSUT))
}
Method (_STM, 3, NotSerialized)
{
Store (Arg0, TMD0)
Store (PMPT, GMPT)
Store (PMUE, GMUE)
Store (PMUT, GMUT)
Store (PSPT, GSPT)
Store (PSUE, GSUE)
Store (PSUT, GSUT)
STM ()
Store (GMPT, PMPT)
Store (GMUE, PMUE)
Store (GMUT, PMUT)
Store (GSPT, PSPT)
Store (GSUE, PSUE)
Store (GSUT, PSUT)
}
Device (CHN1)
{
Name (_ADR, 0x01)
Method (_GTM, 0, NotSerialized)
{
Return (GTM (SMPT, SMUE, SMUT, SSPT, SSUE, SSUT))
}
Method (_STM, 3, NotSerialized)
{
Store (Arg0, TMD0)
Store (SMPT, GMPT)
Store (SMUE, GMUE)
Store (SMUT, GMUT)
Store (SSPT, GSPT)
Store (SSUE, GSUE)
Store (SSUT, GSUT)
STM ()
Store (GMPT, SMPT)
Store (GMUE, SMUE)
Store (GMUT, SMUT)
Store (GSPT, SSPT)
Store (GSUE, SSUE)
Store (GSUT, SSUT)
}
Method (GTM, 6, Serialized)
{
Store (Ones, PIO0)
Store (Ones, PIO1)
Store (Ones, DMA0)
Store (Ones, DMA1)
Store (0x10, CHNF)
If (REGF) {}
Else
{
Return (TMD0)
}
Store (Match (DerefOf
Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23
Hi, On Sun, Dec 09, 2007 at 10:36:42PM +0100, Andreas Mohr wrote: > And the second, possibly much more lucrative, question would be > whether we're actually doing something wrong with our ACPI _GTM execution > which triggers the AE_AML_PACKAGE_LIMIT problem. > > This might help here, perhaps (relevant snippets of AML dump): Indeed, after looking over this horrid ASL stuff for ages I'm now starting to believe that our IDE controller state is wrong, since the Match()ing etc. in this particular _GTM implementation is heavily dependant on actual PCI values (it references some PCI_Config OperationRegion:s), and some indexing seems to go wrong due to this. IOW, it seems very likely that _GTM on these BIOSes (VIA chipsets) isn't actually wrongly implemented but simply expects IDE controller values to have been set up ""differently"". Or... one could possibly even infer from this that - maybe - the _GTM invocation spot is wrong, it should be done somewhere different during bootup. Or whatever. This seems to tell me again that we're often quick to blacklist or whitelist things left and right when instead fundamental problems are hidden somewhere. Still investigating, Andreas Mohr -- 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.24-rc4-git5: Reported regressions from 2.6.23
On Mon, Dec 10, 2007 at 01:04:31AM +0100, Andreas Mohr wrote:
> IOW, it seems very likely that _GTM on these BIOSes (VIA chipsets) isn't
> actually wrongly implemented but simply expects IDE controller values
> to have been set up ""differently"".
>
>
> Or... one could possibly even infer from this that - maybe -
> the _GTM invocation spot is wrong, it should be done somewhere
> different during bootup. Or whatever.
"Whatever" indeed:
There's an ASL Match() for a "PMPT" (Primary Master PorT) PCI register,
and the possible register values are:
Package (0x04)
{
0x20,
0x31,
0x65,
0xA8
},
and from
OperationRegion (CFG2, PCI_Config, 0x40, 0x20)
Field (CFG2, DWordAcc, NoLock, Preserve)
{
Offset (0x08),·
SSPT, 8,·
SMPT, 8,·
PSPT, 8,·
PMPT, 8,·
Offset (0x10),·
...
we can infer that at PCI_Config offset 0x48 those values should be located.
However after bootup or resume there are:
# lspci -s 00:11.1 -xxx
00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e4 00 00 00 00 00 00 00 00 00 00 06 11 71 05
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 00 00
40: 0b 32 09 0a 18 1c c0 00 99 99 20 20 ff 00 a8 20
50: 07 07 f6 f1 14 03 00 00 a8 a8 a8 a8 00 00 00 00
60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00
70: 02 01 00 00 00 00 00 00 82 01 00 00 00 00 00 00
80: 00 e0 a1 1f 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 06 00 71 05 06 11 71 05 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00
As one can see, the relevant values for SSPT, SMPT, PSPT and PMPT are
99 99 20 20, which are not quite entirely valid judging from the array above,
and this is because the secondary port is unused, as can also be seen
from my bootup log:
scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xe400 irq 14
ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xe408 irq 15
ata1.00: ATA-5: WDC WD1200JB-00CRA1, 17.07W17, max UDMA/100
ata1.00: 234441648 sectors, multi 16: LBA
ata1.01: ATAPI: TOSHIBA DVD-ROM SD-M1612, 1004, max UDMA/33
Switched to high resolution mode on CPU 0
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/33
ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0) is
beyond end of object [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.GTM_]
(Node df80b9a8), AE_AML_PACKAGE_LIM
IT
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.IDE0.CHN1._GTM] (Node df80b8d0), AE_AML_PACKAG
E_LIMIT
ata2: ACPI get timing mode failed (AE 0x300d)
Manually tweaking the values to 20 20 20 20 truly does skip the _GTM failure
message on suspend -
only to reappear right on resume due to 99 99 20 20 combo happening again.
If I don't tweak, I get _GTM failure at both suspend and resume.
As such one can conclude that this BIOS is rather very confused when being
called for _GTM on an entirely
unused controller port. And this is either because the BIOS is dumb or because
ACPI doesn't really
expect anyone to call _GTM on an unused physical port. I'd bet on the latter...
(however I haven't found ACPI 3.0b explicitly mentioning this somewhere yet)
Andreas Mohr
--
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.24-rc6-mm1
Hi, another one most likely related to the recent NFS_V4 define build error saga: CC fs/nfs/super.o fs/nfs/super.c: In function 'nfs_sb_deactive': fs/nfs/super.c:338: error: 'TASK_NORMAL' undeclared (first use in this function) fs/nfs/super.c:338: error: (Each undeclared identifier is reported only once fs/nfs/super.c:338: error: for each function it appears in.) fs/nfs/super.c: In function 'nfs_put_super': fs/nfs/super.c:349: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function) fs/nfs/super.c:349: error: implicit declaration of function 'schedule' make[3]: *** [fs/nfs/super.o] Error 1 make[2]: *** [fs/nfs] Error 2 make[1]: *** [fs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.24-rc6-mm1.system-gate-patch' make: *** [debian/stamp-build-kernel] Error 2 This was hand-patched from earlier kernel versions, however I wouldn't think there was any problem due to this (a cleanly extracted version doesn't show any md5sum difference for fs/nfs/super.c). [plus hotfix x86-fix-system-gate-related-crash.patch] I'm circa 120% sure there must be a sched.h include missing there, given the whereabouts of these APIs ;) CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set CONFIG_NFS_V4=y # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V3_ACL is not set CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_NFS_COMMON=y i386 [EMAIL PROTECTED], gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
te=01, sec-latency=64
I/O behind bridge: d000-dfff
Memory behind bridge: ec00-edff
Prefetchable memory behind bridge: e000-e7ff
00:09.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100]
(rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at f010 (32-bit, non-prefetchable) [size=4K]
I/O ports at e000 [size=64]
Memory at f000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at ee00 [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
00:0f.0 Ethernet controller: 3Com Corporation 3c905B Deluxe Etherlink
10/100/BNC [Cyclone]
Subsystem: 3Com Corporation 3c905B Deluxe Etherlink 10/100/BNC [Cyclone]
Flags: bus master, medium devsel, latency 64, IRQ 10
I/O ports at e400 [size=128]
Memory at f0101000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at ef00 [disabled] [size=128K]
Capabilities: [dc] Power Management version 1
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
7000/VE] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc Unknown device 110a
Flags: bus master, stepping, 66MHz, medium devsel, latency 64
Memory at e000 (32-bit, prefetchable) [size=128M]
I/O ports at d000 [size=256]
Memory at ed00 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at ec00 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
Thanks,
Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
Hi, On Thu, Dec 27, 2007 at 09:41:45PM +0300, Alexey Dobriyan wrote: > On Thu, Dec 27, 2007 at 06:40:56PM +0100, Andreas Mohr wrote: > > On Fri, Dec 07, 2007 at 02:23:42AM -0800, Andrew Morton wrote: > > > > (commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416) > > > > > > > > This seems to have broken the use of /proc/bus/usb as a mountpoint. It > > > > always appears empty now, whatever's supposed to be mounted there. > > > > > > > > > > Yes. Denis and Eric are tossing around competing patches but afaik nobody > > > is happy with any of them. Guys, could we get this sorted soonish please? > > > > "Soonish" being rather earlier than 20071227? > > 'cause it's still throwing a fit for me on 2.6.24-rc6-mm1(!) (plus hotfix), > > nothing visible in /proc/bus/usb, thus WLAN driver won't probe > > anything. > > Patch which restores usual behaviour was merged in 2.6.24-rc5 > (3790ee4bd86396558eedd86faac1052cb782e4e1 "proc: remove/Fix proc generic > d_revalidate") Via a kerneltrap.org article (problematic internet setup here currently, non-C&P text terminal only) I could see that this is the patch which removes the d_revalidate member and the corresponding proc_revalidate_dentry(). And this is the state that my 2.6.24-rc_six_-mm1 tree is in already. So either it didn't help here or it broke again by some later change or there's some dumb PEBKAC error here. > so no hotfixes are needed. I just checked with bind mounting / to > /proc/bus/usb -- it works. OK, I'll try to re-check manual, raw, bare-metal mounting (bind etc.) soonish. "CONFIG_NETNS" as mentioned in the patch description actually seems to be "CONFIG_NET_NS", BTW. (which I DON'T have set at the moment, if this happens to make a difference) Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
Hi, On Fri, Dec 28, 2007 at 09:22:01AM +0300, Alexey Dobriyan wrote: > On Thu, Dec 27, 2007 at 11:17:28PM +0100, Andreas Mohr wrote: > > And this is the state that my 2.6.24-rc_six_-mm1 tree is in already. > > OK. > > > So either it didn't help here or it broke again by some later change or > > there's some dumb PEBKAC error here. > > Do you by chance forgot CONFIG_USB_?HCI_HCD=y ? I see empty usbfs here if > they are deselected. Quite well-educated guess! In fact I had already discovered that ohci-hcd fails to load, at all. Doh. (however after going through all recent ohci.*hcd related LKML postings it seems there's no report about such problems yet) Sorry for barking up the entirely wrong tree! For giggles, here's the output: # modprobe ohci-hcd FATAL: Error inserting ohci_hcd (/lib/modules/2.6.24-rc6-mm1-gate/kernel/drivers/usb/host/ohci-hcd.ko): No such device dmesg: ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd: block sizes: ed 64 td 64 (yes, that's all there is, despite CONFIG_USB_DEBUG being set) The LED of a usb stick isn't active either, for obvious reasons. And keep in mind that this is a (relatively old) OHCI-only machine... (which had the 2.6.19 lsmod showing ohci-hcd just fine and working fine with WLAN USB) Now pondering whether to try -rc6 proper or whether to revert specific guilty-looking USB changes... And wondering how to properly elevate this issue (prompt Greg about it, new thread, bug #, ...?) Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH] e100 driver didn't support any MII-less PHYs...
Hi all,
I was mildly annoyed when rebooting my _headless_ internet gateway after a
hotplug -> udev migration and witnessing it not coming up again,
which turned out to be due to an eepro100 / e100 loading conflict
since eepro100 supported both of my Intel-based network cards,
whereas e100 only supported the "newer" one and entirely failed on ifup...
(udev had somehow managed to tweak loading sequence as compared to
a hotplug setup, which caused the drivers to probe differently)
After investigating this e100 failure for half an hour it was obvious
that it was failing in e100_hw_init() -> e100_phy_init() since the driver was
prepared to handle MII-capable PHYs only, not certain older(?) MII-less
PHYs such as 80c24 or i82503.
Investigating some FreeBSD etc. drivers it became terribly clear that there
are also some MII-less PHYs and that one would have to handle them properly.
Thus I decided to add support for those:
- after PHY init failure, try to detect whether the EEPROM lists one of
the MII-less PHYs
- if so, don't fatally fail PHY init function
- avoid touching MII in various utility functions in case of MII-less
PHY (FIXME: this may need review, it was a quick hack in some places)
- add some proper logging on init failure
Note that this is an initial, semi-rough patch only, would love to have
it corrected/improved by the e1000 team.
(I also added some spelling updates for good measure, these would have
to be committed separately obviously)
Frankly I'm quite uncertain as to why one would try to actively deprecate
a driver which works for many cards with a newer one which fails to work
for several card types and doesn't seem clearly superiour in hindsight
after going through it...
Oh, right, that's in order to brute-force people to report any
nagging problems with the new driver, which is... errm... very
understandable after all ;)
(I hope that me "reporting" this problem via a patch is ok ;)
For reference, I'm using a BNC/AUI/TP PCI combo card
Intel 82557 645477-004 FCC ID EJMNPDEPR10PCTPCI
This mail written using a reassuringly stable connection over the newly
adapted driver...
Thanks,
Andreas Mohr
Signed-off-by: Andreas Mohr <[EMAIL PROTECTED]>
--- linux-2.6.24-rc6/drivers/net/e100.c.orig2007-12-28 18:05:39.0
+0100
+++ linux-2.6.24-rc6/drivers/net/e100.c 2007-12-29 00:19:25.0 +0100
@@ -94,7 +94,7 @@
* enabled. 82557 pads with 7Eh, while the later controllers pad
* with 00h.
*
- * IV. Recieve
+ * IV. Receive
*
* The Receive Frame Area (RFA) comprises a ring of Receive Frame
* Descriptors (RFD) + data buffer, thus forming the simplified mode
@@ -113,7 +113,7 @@
* and Rx indication and re-allocation happen in the same context,
* therefore no locking is required. A software-generated interrupt
* is generated from the watchdog to recover from a failed allocation
- * senario where all Rx resources have been indicated and none re-
+ * scenario where all Rx resources have been indicated and none re-
* placed.
*
* V. Miscellaneous
@@ -251,6 +251,7 @@
mac_unknown = 0xFF,
};
+/* FIXME: these are unused: what the heck?? */
enum phy {
phy_100a = 0x03E0,
phy_100c = 0x035002A8,
@@ -352,8 +353,12 @@
op_ewen = 0x13,
};
+enum phy_chips { NonSuchPhy=0, I82553AB, I82553C, I82503, DP83840, S80C240,
+S80C24, I82555, DP83840A=10, };
+
enum eeprom_offsets {
eeprom_cnfg_mdix = 0x03,
+ eeprom_phy_iface = 0x06,
eeprom_id = 0x0A,
eeprom_config_asf = 0x0D,
eeprom_smbus_addr = 0x90,
@@ -553,6 +558,7 @@
multicast_all = (1 << 2),
wol_magic = (1 << 3),
ich_10h_workaround = (1 << 4),
+ phy_is_non_mii = (1 << 5),
} flags cacheline_aligned;
enum mac mac;
@@ -596,6 +602,11 @@
(void)ioread8(&nic->csr->scb.status);
}
+static inline int e100_phy_supports_mii(struct nic *nic)
+{
+ return ((nic->flags & phy_is_non_mii) == 0);
+}
+
static void e100_enable_irq(struct nic *nic)
{
unsigned long flags;
@@ -947,7 +958,7 @@
/* Quadwords to DMA into FIFO before starting frame transmit */
nic->tx_threshold = 0xE0;
- /* no interrupt for every tx completion, delay = 256us if not 557*/
+ /* no interrupt for every tx completion, delay = 256us if not 557 */
nic->tx_command = cpu_to_le16(cb_tx | cb_tx_sf |
((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));
@@ -980,7 +991,8 @@
config->standard_stat_counter = 0x1;/* 1=standard, 0=extended */
config->rx_discard_short_frames = 0x1; /* 1=discard, 0=pass */
config->tx_underrun_retry = 0x3;
Re: IDE/ACPI related hibernation regression: Second attempt fails
[added Tejun and Rafael CCs] Hi, On Mon, Dec 31, 2007 at 01:27:50PM -0800, Mikko Vinni wrote: > Hi, > > I noticed my ancient laptop (HP nx9005) fails to hibernate (suspend to disk) > more than once while running recent 2.6.24-rc kernels. First hibernation > succeeds happily, but when I try to do it again after resuming, the machine > hangs immediately after the familiar two pops from the speakers."Hanging" in > this case means that none of the usual keys work (e.g. Caps Lock led doesn't > toggle), but alt-sysrq-b does reboot the laptop. I'm sorry, but "recent 2.6.24-rc kernels" unfortunately is a statement almost as broad as "there's a violent fire in India, please come and rescue us!", given that this very issue has been handled with lots of activity by Tejun Heo recently (see bug #9530 and http://lkml.org/lkml/2007/12/9/184 for details). 2.6.24-rc6 is the version that has all ACPI IDE fixes in a state that made my system fully work, so there should be a sizeable chance that it works for you, too, hopefully. What's interesting is that you're ALi-based, whereas I'm VIA-based, so your problem might still be unsupported by -rc6 after all. > Dmesg of the failing kernel after first hibernation (version is untouched > e697789d64f8748cb219d7f5c413c512953802cc, i.e. current 2.6.24-rc6): ^ Argh, just saw this at the very last moment, IOW if this is _really_ -rc6+ already then we certainly do have a problem. Disassembled ACPI BIOS AML code (DSDT) of your machine would be very useful in this case, I'm afraid (done via acpidump and iasl, search the internet for pointers). lspci -x or better -xxx of the IDE device would be very useful, too. Thanks for your verbose report, Andreas Mohr -- 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] e100 driver didn't support any MII-less PHYs...
Hi,
On Sat, Dec 29, 2007 at 09:54:45PM -0800, Kok, Auke wrote:
> ok, barely glanced over the patch but it might just be fine. Can you split up
> this
> patch and send a separate patch for the spelling mistakes? I'll then have some
> quick testing done on the result and do a bit deeper review after newyears.
Thanks for your quick reply!
OK, here's part 1, the MII-less support stuff.
(preliminary posting, for review only)
Note that these diffs apply to 2.6.24-rc6-mm1 without much trouble,
thus might want to do -mm testing soon.
Signed-off-by: Andreas Mohr <[EMAIL PROTECTED]>
--- linux-2.6.24-rc6/drivers/net/e100.c 2008-01-01 12:57:06.0 +0100
+++ linux-2.6.24-rc6/drivers/net/e100.c 2008-01-01 16:17:45.0 +0100
@@ -251,6 +251,7 @@
mac_unknown = 0xFF,
};
+/* FIXME: these are unused: what the heck?? */
enum phy {
phy_100a = 0x03E0,
phy_100c = 0x035002A8,
@@ -352,8 +353,12 @@
op_ewen = 0x13,
};
+enum phy_chips { NonSuchPhy=0, I82553AB, I82553C, I82503, DP83840, S80C240,
+S80C24, I82555, DP83840A=10, };
+
enum eeprom_offsets {
eeprom_cnfg_mdix = 0x03,
+ eeprom_phy_iface = 0x06,
eeprom_id = 0x0A,
eeprom_config_asf = 0x0D,
eeprom_smbus_addr = 0x90,
@@ -553,6 +558,7 @@
multicast_all = (1 << 2),
wol_magic = (1 << 3),
ich_10h_workaround = (1 << 4),
+ phy_is_non_mii = (1 << 5),
} flags cacheline_aligned;
enum mac mac;
@@ -596,6 +602,11 @@
(void)ioread8(&nic->csr->scb.status);
}
+static inline int e100_phy_supports_mii(struct nic *nic)
+{
+ return ((nic->flags & phy_is_non_mii) == 0);
+}
+
static void e100_enable_irq(struct nic *nic)
{
unsigned long flags;
@@ -980,7 +991,8 @@
config->standard_stat_counter = 0x1;/* 1=standard, 0=extended */
config->rx_discard_short_frames = 0x1; /* 1=discard, 0=pass */
config->tx_underrun_retry = 0x3;/* # of underrun retries */
- config->mii_mode = 0x1; /* 1=MII mode, 0=503 mode */
+ if (e100_phy_supports_mii(nic))
+ config->mii_mode = 1; /* 1=MII mode, 0=i82503 mode */
config->pad10 = 0x6;
config->no_source_addr_insertion = 0x1; /* 1=no, 0=yes */
config->preamble_length = 0x2; /* 0=1, 1=3, 2=7, 3=15 bytes */
@@ -1350,6 +1362,42 @@
offsetof(struct mem, dump_buf));
}
+static int e100_phy_check_without_mii(struct nic *nic)
+{
+ u8 phy_type;
+ int without_mii;
+
+ phy_type = (nic->eeprom[eeprom_phy_iface] >> 8) & 0x0f;
+
+ switch (phy_type) {
+ case NonSuchPhy: /* Non-MII PHY; UNTESTED! */
+ case I82503: /* Non-MII PHY; UNTESTED! */
+ case S80C24: /* Non-MII PHY; tested and working */
+ {
+ /* paragraph from the FreeBSD driver, "FXP_PHY_80C24":
+* The Seeq 80c24 AutoDUPLEX(tm) Ethernet Interface Adapter
+* doesn't have a programming interface of any sort. The
+* media is sensed automatically based on how the link partner
+* is configured. This is, in essence, manual configuration.
+*/
+ DPRINTK(PROBE, INFO, "found MII-less i82503 or 80c24 or other
PHY\n");
+ nic->mii.phy_id = 0; /* is this ok for an MII-less PHY? */
+
+ /* these might be needed for certain MII-less cards...
+* nic->flags |= ich;
+* nic->flags |= ich_10h_workaround; */
+
+ nic->flags |= phy_is_non_mii;
+ without_mii = 1;
+ }
+ break;
+ default:
+ without_mii = 0;
+ break;
+ }
+ return without_mii;
+}
+
#define NCONFIG_AUTO_SWITCH0x0080
#define MII_NSC_CONG MII_RESV1
#define NSC_CONG_ENABLE0x0100
@@ -1370,9 +1418,21 @@
if(!((bmcr == 0x) || ((stat == 0) && (bmcr == 0
break;
}
- DPRINTK(HW, DEBUG, "phy_addr = %d\n", nic->mii.phy_id);
- if(addr == 32)
- return -EAGAIN;
+ if(addr == 32) {
+ /* uhoh, no PHY detected: check whether we seem to be some
+* weird, rare variant which is *known* to not have any MII.
+* But do this AFTER MII checking only, since this does
+* lookup of EEPROM values which may easily be unreliable. */
+ if (e100_phy_check_without_mii(nic))
+ return 0; /* simply return and hope for the best */
+ else {
+
Re: [RFC/PATCH] e100 driver didn't support any MII-less PHYs...
Hi,
On Sat, Dec 29, 2007 at 09:54:45PM -0800, Kok, Auke wrote:
> ok, barely glanced over the patch but it might just be fine. Can you split up
> this
> patch and send a separate patch for the spelling mistakes? I'll then have some
> quick testing done on the result and do a bit deeper review after newyears.
Part 2, the spelling corrections.
Thanks!
Signed-off-by: Andreas Mohr <[EMAIL PROTECTED]>
--- linux-2.6.24-rc6/drivers/net/e100.c 2008-01-01 18:53:21.0 +0100
+++ linux-2.6.24-rc6/drivers/net/e100.c 2008-01-01 18:53:25.0 +0100
@@ -94,7 +94,7 @@
* enabled. 82557 pads with 7Eh, while the later controllers pad
* with 00h.
*
- * IV. Recieve
+ * IV. Receive
*
* The Receive Frame Area (RFA) comprises a ring of Receive Frame
* Descriptors (RFD) + data buffer, thus forming the simplified mode
@@ -113,7 +113,7 @@
* and Rx indication and re-allocation happen in the same context,
* therefore no locking is required. A software-generated interrupt
* is generated from the watchdog to recover from a failed allocation
- * senario where all Rx resources have been indicated and none re-
+ * scenario where all Rx resources have been indicated and none re-
* placed.
*
* V. Miscellaneous
@@ -958,7 +958,7 @@
/* Quadwords to DMA into FIFO before starting frame transmit */
nic->tx_threshold = 0xE0;
- /* no interrupt for every tx completion, delay = 256us if not 557*/
+ /* no interrupt for every tx completion, delay = 256us if not 557 */
nic->tx_command = cpu_to_le16(cb_tx | cb_tx_sf |
((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));
@@ -1550,7 +1550,7 @@
&s->complete;
/* Device's stats reporting may take several microseconds to
-* complete, so where always waiting for results of the
+* complete, so we're always waiting for results of the
* previous command. */
if(*complete == le32_to_cpu(cuc_dump_reset_complete)) {
@@ -2884,17 +2884,17 @@
/**
* e100_io_error_detected - called when PCI error is detected.
* @pdev: Pointer to PCI device
- * @state: The current pci conneection state
+ * @state: The current pci connection state
*/
static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
- /* Similar to calling e100_down(), but avoids adpater I/O. */
+ /* Similar to calling e100_down(), but avoids adapter I/O. */
netdev->stop(netdev);
- /* Detach; put netif into state similar to hotplug unplug. */
+ /* Detach; put netif into a state similar to hotplug unplug. */
napi_enable(&nic->napi);
netif_device_detach(netdev);
pci_disable_device(pdev);
--
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: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
Hi, On Sun, Dec 30, 2007 at 03:34:45PM -0500, Alan Stern wrote: > It looks like Greg misused the debugfs API -- which is ironic, because > he wrote debugfs in the first place! :-) > > Let me know if this patch fixes the problem. If it does, I'll submit > it to Greg with all the proper accoutrements. Finally a 2.6.24-rc6-mm1 with working USB WLAN. :) IOW I can confirm that this was the cause of the USB problem I was having. Thanks! Andreas Mohr -- 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: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
Hi, On Tue, Jan 01, 2008 at 10:00:06PM -0800, Greg KH wrote: > Ok, no, I didn't write that patch, I'm getting very confused here. > > In 2.6.24-rc6 there is no usage of debugfs in the ohci driver. > > In the -mm tree there is a patch, from Tony Jones, that moves some debug > code out of sysfs and into debugfs where it belongs. It does it for > both the ehci and ohci USB host controller drivers, and this is the code > that is incorrect if CONFIG_DEBUGFS is not enabled. > > So, for the 2.6.24 release, nothing needs to be changed, all is good, > and there is no regression. > > Right? Or am I still confused about this whole thing? Probably, since I also wasn't sure about this getting added to the post-2.6.23 regressions. I'd expect this problem to be -mm only myself, but then I didn't actively verify it in code (and I haven't tried -rc6 proper on that machine yet either, build takes ages ;). OK, since I cannot really offer anything other than positive feelings about this being non-rc6 breakage, should I try -rc6 proper, too? > Hm, I wonder if this means I can go back to drinking more holiday > wine... :) .even more confusion? :) Thanks for your help, Andreas Mohr -- 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: forcedeth: MAC-address reversed on resume from suspend
Hi, On Wed, Jan 02, 2008 at 10:04:49PM +0100, Richard Jonsson wrote: > Bugreport regarding forcedeth driver. > > When returning from suspend-to-RAM the MAC-address byteorder is reversed. > After another suspend-resume cycle the MAC-address is again correct. This > brings a great deal of pain since the NIC is assigned a random MAC-address > when it is detected as invalid. > > I cannot say if this issue appeared recently or if it's been in the kernel > for a while, as I've been using wireless until recently. > > I read somewhere on lkml that the mac is read from the device, then > reversed and finally written back to the device. Can it be that it is read > again on resume and reversed, and then again written to the device? This > would explain why it's ok every other resume cycle. Uh, Use The Source, Luke? But no, I think it's simply driver dainbreadness, not a matter of complicated writing and reading back in reversed order. drivers/net/forcedeth.c has a nice DEV_HAS_CORRECT_MACADDR flag which is being enabled for certain cards (those which need this) and disabled for others. The nv_probe() function then nicely obeys this flag by reversing the address if needed, _however_ there's another function, nv_copy_mac_to_hw(), which does _NOT_ obey it and simply copies the _raw_ netdev dev_addr to the card register (NvRegMacAddrA etc.). I don't know, this all looks a bit dirty to me, MAC reading/writing should have been implemented in a more central way, then those people wouldn't have confused heaven and hell with MAC address fiddling. And yeah, this certainly looks like a bug that should be fixed ASAP, unless my short analysis somehow happened to be wrong. (I could probably fix it, but then the forcedeth people most likely know better how they would like to see it implemented) Thank you for your report! Now the only thing remaining would be: is there a specific way to contact forcedeth-related people? I didn't find anything within a short search. Andreas Mohr -- 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] e100 driver didn't support any MII-less PHYs...
Hi, On Tue, Jan 01, 2008 at 09:09:08PM +0100, Andreas Mohr wrote: > Thanks for your quick reply! > > OK, here's part 1, the MII-less support stuff. > (preliminary posting, for review only) > > Note that these diffs apply to 2.6.24-rc6-mm1 without much trouble, > thus might want to do -mm testing soon. Any verdict on this one? I happen to be asking now since silly me just ""upgraded"" a mere mortal's sorta-production machine to 2.6.24 proper without remembering that the previous -rc6 had contained a minor but effective change to make those wires do their thing. Or, to tell it as it was, "Mom wasn't impressed ;)". Perhaps it's useful to file a bug/patch on http://sourceforge.net/projects/e1000/ ? Perhaps -mm testing? Thanks, Andreas Mohr -- 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] e100 driver didn't support any MII-less PHYs...
Hi, On Tue, Jan 29, 2008 at 03:09:25PM -0800, Kok, Auke wrote: > Andreas Mohr wrote: > > Perhaps it's useful to file a bug/patch > > on http://sourceforge.net/projects/e1000/ ? Perhaps -mm testing? > > I wanted to push this though our testing labs first which has not happened > due to > time constraints - that should quickly at least confirm that the most common > nics > work OK after the change with your patch. I'll try and see if we can get this > testing done soon. Oh, full-scale regression testing even? Nice idea... Would optionally be even better if during hardware tests one could also dig out some i82503-based card (or additional MII-less cards?) since I didn't really make any effort yet to try to make them all recognized/supported by my patch already (would have been out of scope anyway since I have this single card only). Thanks a lot, Andreas Mohr -- 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: cannot find directory on cdrom
On Thu, May 03, 2001 at 08:29:02AM +0100, Richard Polton wrote: > Hi, > > I have a cdrom burnt by a friend with W2000 (I know, friends don't let > friends use W ;-) which has (at least) one directory on it which I > cannot > see when mounting the disk under linux. I am using kernel 2.4.4 and > the mount command is the usual > > mount /dev/cdrom /mnt/cdrom -t iso9660 > > I have Joliet compiled into the kernel too. I can send by private email > the > first 120 blocks or so of the disk if anyone is interested. I looked at > this > with hexlify and can see the mysterious directory (s?) which is called > 'sturf'. > > Thanks, > > Richard Hmm, is this the old "non-standard sector alignment" problem ? Some CDs have their directory sector entries exceed the sector, and AFAIK the problem is that they exceed it not entry by entry, but in the middle of a directory entry, which violates the ISO9660 spec. The Linux CD-ROM driver used to have a workaround for this, but then after 2.0.x it seems to have been removed. Why ??? After all Windows perfectly accepts these broken (ISO9660 wise) CD-ROMs. I don't know whether 2.4.x still has the same "feature" that 2.2.x had. A Spanish language training CD of mine has this problem, and I can't read several files on it. Hmm, or maybe your problem is simply that you forgot to enable the "hidden" mount option for your CD-ROM ?? (some files are burnt with "hidden" attribute !) Andreas Mohr - 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/
OOPS: PPA ZIP 2.4.3 (semi-debugged)
rev] spin_unlock_irqrestore(&tqueue_lock, flags);: spin_unlock(&tqueue_lock);: local_irq_restore(flags);: 0xc018bc7a : push %eax 0xc018bc7b : popf what's that ??? gcc problem ?: 0xc018bc7c : lea0x0(%esi,1),%esi batch_head = new;: 0xc018bc80 : mov%ecx,0xc027bd64 [batch_head] 0xc018bc86 : ret 0xc018bc87 : nop So can anybody tell me why it crashes at 0xc018bc74 ? Note that I'm not sure whether the suspend is required for the OOPS; I don't know any other way of triggering the OOPS, though. BTW, if I reconnect the cable instead of unloading ppa, I get: root@note:/root# ppa: Parallel port cable is unplugged!! ppa: Parallel port cable is unplugged!! ppa: Parallel port cable is unplugged!! sda : READ CAPACITY failed. sda : status = 0, message = 00, host = 1, driver = 00 sda : sense not available. sda : block size assumed to be 512 bytes, disk size 1GB. /dev/scsi/host0/bus0/target6/lun0: I/O error: dev 08:00, sector 0 So it seems to try to do a READ CAPACITY call at this moment upon resume, which maybe blocks the kernel somehow when no cable is available... Thank you for any suggestions ! I'm subscribed to the list, so no need to CC. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.germany.net/100-30936/ - 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: Whether can we put our company's linux driver into linux kernel?
On Thu, May 03, 2001 at 03:06:24PM -, mirabilos wrote: > Hmmm is he sure he knows what linux is...? > I dunno whether he has understood the concept right, > maybe he'll post a WDM driver ;-) > > -mirabilos Hey, come on, this is a legitimate question. It's been a bit "uninformed", yes, but that's not really an excuse for making such comments ;-) Furthermore you posted this with a Windoze client (outlock), so it's even less of an excuse :) To the original poster: I'm not really authoritative on driver submission, but I'd read the file /usr/src/linux/SubmittingDrivers for info on how to do that, if I were you. New VIA drivers are very good for Linux anyway ! :-) (thanks !) Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] eradicate bashisms in scripts/patch-kernel
Hi,
On Wed, Nov 14, 2007 at 02:46:27PM -0800, Randy Dunlap wrote:
> On Mon, 5 Nov 2007 20:58:27 +0100 Andreas Mohr wrote:
> > Feel free to go ahead, otherwise I'll try another patch sometime soon.
> > All I care about is that the result works on (at least)
> > one shell implementation _more_ than the current status ;)
>
> Hi Andreas,
>
> Can you comment on (or test) whether this patch is sufficient
> for your needs? And if so, is the Signed-off-by: A.M. OK?
Sorry, no, using dash (0.5.3-5) there's still a remaining
$ linux-2.6.22/scripts/patch-kernel linux-2.6.22 /usr/src/patch-2.6
Current kernel version is 2.6.22 ( Holy Dancing Manatees, Batman!)
linux-2.6.22/scripts/patch-kernel: 207: Syntax error: Bad substitution
error in the
# strip EXTRAVERSION to just a number (drop leading '.' and trailing additions)
EXTRAVER=
if [ x$EXTRAVERSION != "x" ]
then
>>> [l.207] if [ ${EXTRAVERSION:0:1} == "." ]; then
EXTRAVER=${EXTRAVERSION:1}
else
EXTRAVER=$EXTRAVERSION
fi
EXTRAVER=${EXTRAVER%%[[:punct:]]*}
#echo "$PNAME: changing EXTRAVERSION from $EXTRAVERSION to $EXTRAVER"
fi
part, which the sed expression (moderately successfully) tried to
take care of.
The good part of the story is that the current corrected almost fully
working version still works with bash (3.1dfsg-8), just like the
original patch-kernel version.
Signed-off-by would be fine by me.
Thanks,
Andreas Mohr
-
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] eradicate bashisms in scripts/patch-kernel
Make the patch-kernel shell script sufficiently compatible with POSIX
shells,
i.e., remove bashisms from scripts/patch-kernel.
This means that it now also works on dash 0.5.3-5
and still works on bash 3.1dfsg-8.
Full changelog:
- replaced non-standard "==" by standard "="
- replaced non-standard "source" statement by POSIX "dot" command
- use leading ./ on mktemp filename to force the tempfile to a local
directory, so that the search path is not used
- replace bash syntax to remove leading dot by similar POSIX syntax
- added missing (optional/not required) $ signs to shell variable names
Signed-off-by: Andreas Mohr <[EMAIL PROTECTED]>
---
Thanks for all comments! I might want to make sure to read more specs
next time...
Cowardly didn't dare to pre-add Randy's line, feel free to ack ;)
--- linux-2.6.23/scripts/patch-kernel.orig 2007-11-17 21:26:47.0
+0100
+++ linux-2.6.23/scripts/patch-kernel 2007-11-17 21:27:59.0 +0100
@@ -65,7 +65,7 @@
patchdir=${2-.}
stopvers=${3-default}
-if [ "$1" == -h -o "$1" == --help -o ! -r "$sourcedir/Makefile" ]; then
+if [ "$1" = -h -o "$1" = --help -o ! -r "$sourcedir/Makefile" ]; then
cat << USAGE
usage: $PNAME [-h] [ sourcedir [ patchdir [ stopversion ] [ -acxx ] ] ]
source directory defaults to /usr/src/linux,
@@ -182,10 +182,12 @@
}
# set current VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
-TMPFILE=`mktemp .tmpver.XX` || { echo "cannot make temp file" ; exit 1; }
+# force $TMPFILEs below to be in local directory: a slash character prevents
+# the dot command from using the search path.
+TMPFILE=`mktemp ./.tmpver.XX` || { echo "cannot make temp file" ; exit 1; }
grep -E "^(VERSION|PATCHLEVEL|SUBLEVEL|EXTRAVERSION)" $sourcedir/Makefile >
$TMPFILE
tr -d [:blank:] < $TMPFILE > $TMPFILE.1
-source $TMPFILE.1
+. $TMPFILE.1
rm -f $TMPFILE*
if [ -z "$VERSION" -o -z "$PATCHLEVEL" -o -z "$SUBLEVEL" ]
then
@@ -202,11 +204,7 @@
EXTRAVER=
if [ x$EXTRAVERSION != "x" ]
then
- if [ ${EXTRAVERSION:0:1} == "." ]; then
- EXTRAVER=${EXTRAVERSION:1}
- else
- EXTRAVER=$EXTRAVERSION
- fi
+ EXTRAVER=${EXTRAVERSION#.}
EXTRAVER=${EXTRAVER%%[[:punct:]]*}
#echo "$PNAME: changing EXTRAVERSION from $EXTRAVERSION to $EXTRAVER"
fi
@@ -251,16 +249,16 @@
do
CURRENTFULLVERSION="$VERSION.$PATCHLEVEL.$SUBLEVEL"
EXTRAVER=
-if [ $stopvers == $CURRENTFULLVERSION ]; then
+if [ $stopvers = $CURRENTFULLVERSION ]; then
echo "Stopping at $CURRENTFULLVERSION base as requested."
break
fi
-SUBLEVEL=$((SUBLEVEL + 1))
+SUBLEVEL=$(($SUBLEVEL + 1))
FULLVERSION="$VERSION.$PATCHLEVEL.$SUBLEVEL"
#echo "#___ trying $FULLVERSION ___"
-if [ $((SUBLEVEL)) -gt $((STOPSUBLEVEL)) ]; then
+if [ $(($SUBLEVEL)) -gt $(($STOPSUBLEVEL)) ]; then
echo "Stopping since sublevel ($SUBLEVEL) is beyond stop-sublevel
($STOPSUBLEVEL)"
exit 1
fi
@@ -297,7 +295,7 @@
if [ x$gotac != x ]; then
# Out great user wants the -ac patches
# They could have done -ac (get latest) or -acxx where xx=version they
want
- if [ $gotac == "-ac" ]; then
+ if [ $gotac = "-ac" ]; then
# They want the latest version
HIGHESTPATCH=0
for PATCHNAMES in $patchdir/patch-${CURRENTFULLVERSION}-ac*\.*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH/RFC] eradicate bashisms in scripts/patch-kernel
Hello,
I was non-mildly horrified to find that the rather widely used patch-kernel
script seems to rely on bash despite specifying the interpreter as #!/bin/sh,
since my dash-using Debian install choked on it.
Thus I'm delivering a first, preliminary, non-reviewed change to make
patch-kernel (a little bit more?) POSIX-compatible. It now survives both
a dash and a bash run.
If this mail goes through relatively unscathed, then it might be a good
idea to plant it into -mm via a follow-up mail.
Comments?
- replaced "==" by "="
- the "source" statement most likely needs the ./ prepended, as can be
gathered from e.g. http://osdir.com/ml/colinux.devel/2005-12/msg00036.html
- the newly replaced sed expression below: is it ok? correct? strict enough?
Thanks,
Andreas Mohr
(who's strongly hoping that submitting a patch for this thingy doesn't
automatically equal becoming "maintainer for life" for it ;)
--- linux-2.6.23/scripts/patch-kernel 2007-10-31 21:55:26.0 +0100
+++ linux-2.6.23/scripts/patch-kernel.dash 2007-10-31 21:58:37.0
+0100
@@ -65,7 +65,7 @@
patchdir=${2-.}
stopvers=${3-default}
-if [ "$1" == -h -o "$1" == --help -o ! -r "$sourcedir/Makefile" ]; then
+if [ "$1" = "-h" -o "$1" = "--help" -o ! -r "$sourcedir/Makefile" ]; then
cat << USAGE
usage: $PNAME [-h] [ sourcedir [ patchdir [ stopversion ] [ -acxx ] ] ]
source directory defaults to /usr/src/linux,
@@ -185,7 +185,7 @@
TMPFILE=`mktemp .tmpver.XX` || { echo "cannot make temp file" ; exit 1; }
grep -E "^(VERSION|PATCHLEVEL|SUBLEVEL|EXTRAVERSION)" $sourcedir/Makefile >
$TMPFILE
tr -d [:blank:] < $TMPFILE > $TMPFILE.1
-source $TMPFILE.1
+. ./$TMPFILE.1
rm -f $TMPFILE*
if [ -z "$VERSION" -o -z "$PATCHLEVEL" -o -z "$SUBLEVEL" ]
then
@@ -202,13 +202,7 @@
EXTRAVER=
if [ x$EXTRAVERSION != "x" ]
then
- if [ ${EXTRAVERSION:0:1} == "." ]; then
- EXTRAVER=${EXTRAVERSION:1}
- else
- EXTRAVER=$EXTRAVERSION
- fi
- EXTRAVER=${EXTRAVER%%[[:punct:]]*}
- #echo "$PNAME: changing EXTRAVERSION from $EXTRAVERSION to $EXTRAVER"
+ EXTRAVER=`echo $EXTRAVERSION|sed -s 's/^[\.]\?\([^[:punct:]]*\).*/\1/'`
fi
#echo "stopvers=$stopvers"
@@ -251,16 +245,16 @@
do
CURRENTFULLVERSION="$VERSION.$PATCHLEVEL.$SUBLEVEL"
EXTRAVER=
-if [ $stopvers == $CURRENTFULLVERSION ]; then
+if [ $stopvers = $CURRENTFULLVERSION ]; then
echo "Stopping at $CURRENTFULLVERSION base as requested."
break
fi
-SUBLEVEL=$((SUBLEVEL + 1))
+SUBLEVEL=$(( $SUBLEVEL + 1 ))
FULLVERSION="$VERSION.$PATCHLEVEL.$SUBLEVEL"
#echo "#___ trying $FULLVERSION ___"
-if [ $((SUBLEVEL)) -gt $((STOPSUBLEVEL)) ]; then
+if [ $SUBLEVEL -gt $STOPSUBLEVEL ]; then
echo "Stopping since sublevel ($SUBLEVEL) is beyond stop-sublevel
($STOPSUBLEVEL)"
exit 1
fi
@@ -297,7 +291,7 @@
if [ x$gotac != x ]; then
# Out great user wants the -ac patches
# They could have done -ac (get latest) or -acxx where xx=version they
want
- if [ $gotac == "-ac" ]; then
+ if [ $gotac = "-ac" ]; then
# They want the latest version
HIGHESTPATCH=0
for PATCHNAMES in $patchdir/patch-${CURRENTFULLVERSION}-ac*\.*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] eradicate bashisms in scripts/patch-kernel
On Wed, Oct 31, 2007 at 03:24:22PM -0700, Randy Dunlap wrote:
> Andreas Mohr wrote:
> >- the "source" statement most likely needs the ./ prepended, as can be
> >gathered from e.g. http://osdir.com/ml/colinux.devel/2005-12/msg00036.html
>
> That email isn't very convincing to me.
Actually that place simply was where I found how the
.: 188: .tmpver.eC4856.1: not found
dash error that happened when I replaced the bash-specific "source"
statement with its "." counterpart could be ""fixed"".
> http://www.opengroup.org/onlinepubs/009695399/utilities/dot.html just says
> that
> if does not contain a slash, the search PATH shall be used
> (searched).
> If you want to prevent that, it's OK to use ./, but at least say that in the
> patch description, please.
So this part seems to indicate that merely prepending ./ is problematic,
since ./ implies relative path resolution whereas $TMPFILE.1 could
theoretically be an absolute path already.
It would probably be best to add the ./ to mktemp already, to make sure
we source *exactly* the filename expression we originally mktemp'd.
OTOH prepending ./ to mktemp by default would deny mktemp any
"search for a temporary-capable directory and create the file there"
capabilities. Hmm. I should investigate POSIX shell sourcing
mechanisms more.
> >@@ -202,13 +202,7 @@
> > EXTRAVER=
> > if [ x$EXTRAVERSION != "x" ]
> > then
> >-if [ ${EXTRAVERSION:0:1} == "." ]; then
> >-EXTRAVER=${EXTRAVERSION:1}
> >-else
> >-EXTRAVER=$EXTRAVERSION
> >-fi
> >-EXTRAVER=${EXTRAVER%%[[:punct:]]*}
> >-#echo "$PNAME: changing EXTRAVERSION from $EXTRAVERSION to $EXTRAVER"
>
> What's the problem above?
The variable manipulation seems bash-specific, the resulting dash error was:
linux-2.6.23/scripts/patch-kernel: 205: Syntax error: Bad substitution
which pointed at the
if [ ${EXTRAVERSION:0:1} == "." ]; then
line.
> >
> >-SUBLEVEL=$((SUBLEVEL + 1))
> >+SUBLEVEL=$(( $SUBLEVEL + 1 ))
>
> Why are the added spaces needed?
They weren't strictly needed, what was needed was to add the missing $ sign
(you could perhaps say that I added the spaces to emphasize the $ sign).
Maybe they're best removed.
> Did you look at
> http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html ?
No. I should have started by looking at the opengroup.org site when
looking for POSIX specs...
>
> > FULLVERSION="$VERSION.$PATCHLEVEL.$SUBLEVEL"
> > #echo "#___ trying $FULLVERSION ___"
> >
> >-if [ $((SUBLEVEL)) -gt $((STOPSUBLEVEL)) ]; then
> >+if [ $SUBLEVEL -gt $STOPSUBLEVEL ]; then
>
> What's the problem here?
I got
linux-2.6.23/scripts/patch-kernel: 270: arith: syntax error: "SUBLEVEL"
thus I simply removed braces since that "fixed" the issue.
May be incorrect, though...
I'll think a bit more about these couple changed places (and whether
this still truly works as intended) and mail a patch then.
(and a big NOTE: I'm no POSIX vs. non-POSIX shell guru at all, only a
semi-versed shell script writer, thus these changes should be reviewed
quite thoroughly)
Thanks for your very fast review,
Andreas Mohr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] eradicate bashisms in scripts/patch-kernel
Hi,
On Thu, Nov 01, 2007 at 08:24:57AM -0700, Randy Dunlap wrote:
> On Thu, 1 Nov 2007 13:11:33 +0100 Andreas Mohr wrote:
> > I'll think a bit more about these couple changed places (and whether
> > this still truly works as intended) and mail a patch then.
> >
> > (and a big NOTE: I'm no POSIX vs. non-POSIX shell guru at all, only a
> > semi-versed shell script writer, thus these changes should be reviewed
> > quite thoroughly)
>
> Neither am I. I read those web pages quickly yesterday, so after
> you read them, we can discuss more and/or review more patches.
OK, next iteration (v2).
Make the patch-kernel shell script sufficiently compatible with POSIX shells.
Changes since v1:
- don't actually change string quoting
- prepend ./ at mktemp step already
- remove added superfluous spaces in arithmetic expression
- don't remove double braces in STOPSUBLEVEL evaluation,
since these are integer values to be compared
Full ChangeLog:
- replaced non-standard "==" by standard "="
- replaced non-standard "source" statement by POSIX "dot" statement
- POSIX shell local file lookup needs ./ prepended, thus have mktemp
use this from the beginning and comment it properly
- replace non-standard bash string parsing by sed expression
(is the sed syntax ok? correct? strict enough?)
- added missing $ signs to shell variable names
About the missing $ signs:
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_14
says:
"If the shell variable x contains a value that forms a valid integer
constant, then the arithmetic expansions
"$((x))" and "$(($x))" shall return the same value."
Hmm, well, seems dash doesn't... (syntax error).
Thus I still needed to add the $ signs despite opengroup.org specifying
it differently.
Updated version verified again to now work with both bash and dash
on Debian stable.
Patch intended for inclusion in -mm, once it has survived some reviews.
Thanks.
Signed-off-by: Andreas Mohr <[EMAIL PROTECTED]>
--- linux-2.6.23/scripts/patch-kernel.orig 2007-11-01 22:51:34.0
+0100
+++ linux-2.6.23/scripts/patch-kernel 2007-11-01 22:10:14.0 +0100
@@ -65,7 +65,7 @@
patchdir=${2-.}
stopvers=${3-default}
-if [ "$1" == -h -o "$1" == --help -o ! -r "$sourcedir/Makefile" ]; then
+if [ "$1" = -h -o "$1" = --help -o ! -r "$sourcedir/Makefile" ]; then
cat << USAGE
usage: $PNAME [-h] [ sourcedir [ patchdir [ stopversion ] [ -acxx ] ] ]
source directory defaults to /usr/src/linux,
@@ -182,10 +182,12 @@
}
# set current VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
-TMPFILE=`mktemp .tmpver.XX` || { echo "cannot make temp file" ; exit 1; }
+# sourcing $TMPFILE.1 below needs lookup in local directory in a POSIX shell,
+# thus prepend ./ to mktemp argument
+TMPFILE=`mktemp ./.tmpver.XX` || { echo "cannot make temp file" ; exit 1; }
grep -E "^(VERSION|PATCHLEVEL|SUBLEVEL|EXTRAVERSION)" $sourcedir/Makefile >
$TMPFILE
tr -d [:blank:] < $TMPFILE > $TMPFILE.1
-source $TMPFILE.1
+. $TMPFILE.1
rm -f $TMPFILE*
if [ -z "$VERSION" -o -z "$PATCHLEVEL" -o -z "$SUBLEVEL" ]
then
@@ -202,13 +204,7 @@
EXTRAVER=
if [ x$EXTRAVERSION != "x" ]
then
- if [ ${EXTRAVERSION:0:1} == "." ]; then
- EXTRAVER=${EXTRAVERSION:1}
- else
- EXTRAVER=$EXTRAVERSION
- fi
- EXTRAVER=${EXTRAVER%%[[:punct:]]*}
- #echo "$PNAME: changing EXTRAVERSION from $EXTRAVERSION to $EXTRAVER"
+ EXTRAVER=`echo $EXTRAVERSION|sed -s 's/^[\.]\?\([^[:punct:]]*\).*/\1/'`
fi
#echo "stopvers=$stopvers"
@@ -251,16 +247,16 @@
do
CURRENTFULLVERSION="$VERSION.$PATCHLEVEL.$SUBLEVEL"
EXTRAVER=
-if [ $stopvers == $CURRENTFULLVERSION ]; then
+if [ $stopvers = $CURRENTFULLVERSION ]; then
echo "Stopping at $CURRENTFULLVERSION base as requested."
break
fi
-SUBLEVEL=$((SUBLEVEL + 1))
+SUBLEVEL=$(($SUBLEVEL + 1))
FULLVERSION="$VERSION.$PATCHLEVEL.$SUBLEVEL"
#echo "#___ trying $FULLVERSION ___"
-if [ $((SUBLEVEL)) -gt $((STOPSUBLEVEL)) ]; then
+if [ $(($SUBLEVEL)) -gt $(($STOPSUBLEVEL)) ]; then
echo "Stopping since sublevel ($SUBLEVEL) is beyond stop-sublevel
($STOPSUBLEVEL)"
exit 1
fi
@@ -297,7 +293,7 @@
if [ x$gotac != x ]; then
# Out great user wants the -ac patches
# They could have done -ac (get latest) or -acxx where xx=version they
want
- if [ $gotac == "-ac" ]; then
+ if [ $gotac = "-ac" ]; then
# They want the latest version
HIGHESTPATCH=0
for PATCHNAMES in $patchdir/patch-${CURRENTFULLVERSION}-ac*\.*
-
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/
HPET force-enable investigations on Via VT8235 (was: Re: extra timer interrupt + konqueror)
[CC'd LKML for broader testing] Hi, On Sat, Aug 04, 2007 at 12:58:20PM -0400, David Edwards wrote: > Andreas Mohr wrote: > >> Same for "hpet-force-enable-on-vt8235-37-chipsets.patch" (I use this > >> one on my Asrock P4VT8+ motherboard (VT8237 based) with no pb). > > > > What!?!?!? > > Why did nobody tell me that VT8235 *does* actually have a HPET > > implementation? ;) > > I've been investigating this during a couple evenings some months ago, > > with apparently negative result for my VT8235 (blank I/O area at the > > place where VT8237 has its HPET, and I wasn't able to activate anything), > > which I then reported on LKML. > > And now you report that one found that it's actually possible. Yay!! > > Erm... Don't get too excited. The HPET patch does not enable the HPET on > my VT8235 (EPIA ME-6000 mini-itx board), so it may not be universally > functional. > > > I'm going to test this patch on my EPOX 8K5A2+ (VT8235, i.e. PCI ID 0x3177). > > Cool. Let me know if it works for you. :) Err... nope. :(( I've added the full 2.6.23-rc1-hrt1 patchset (http://www.tglx.de/projects/hrtimers/2.6.23-rc1/patch-2.6.23-rc1-hrt1.patch), and I do get the "Failed to force enable HPET", so I know it's running that function, however it fails since the 0x80 bit is NOT set after the force-enable (which sadly happens to match my experience during my much earlier efforts to try to get HPET to work on this board). So, *please* (I'd *love* to get this working somehow): whoever has a VT8235 and is listening here, - give a "lspci -nn" (two 'n'!), to figure out details of chipset revision etc. - give a "lspci -d 1106:3177 -xxx", to try to figure out whether there happen to be additional magical "enable" bits to map in those HPET I/O areas which some BIOS versions configure and some don't (that's my fragile theory at least) - oh, and don't forget to tell whether HPET works or not For my system (again, it's EPOX 8K5A2+ with VT8235): [EMAIL PROTECTED]:/usr/src/linux-2.6.23-rc1-hrt1# lspci -nn 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] [1106:3099] 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] [1106:b099] 00:09.0 FireWire (IEEE 1394) [0c00]: Duet Technologies Unknown device [1306:3044] (rev 46) 00:0a.0 Multimedia audio controller [0401]: Aureal Semiconductor Vortex 2 [12eb:0002] (rev fe) 00:0c.0 Ethernet controller [0200]: Intel Corporation 82557/8/9 [Ethernet Pro 100] [8086:1229] (rev 08) 00:0d.0 Multimedia audio controller [0401]: Aztech System Ltd 3328 Audio [122d:50dc] (rev 10) 00:10.0 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.1 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.2 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.3 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 82) 00:11.0 ISA bridge [0601]: VIA Technologies, Inc. VT8235 ISA Bridge [1106:3177] 00:11.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) 00:11.5 Multimedia audio controller [0401]: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller [1106:3059] (rev 50) 00:12.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6102 [Rhine-II] [1106:3065] (rev 74) 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon RV250 If [Radeon 9000] [1002:4966] (rev 01) 01:00.1 Display controller [0380]: ATI Technologies Inc Radeon RV250 [Radeon 9000] (Secondary) [1002:496e] (rev 01) [EMAIL PROTECTED]:/usr/src/linux-2.6.23-rc1-hrt1# lspci -d 1106:3177 -xxx 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00: 06 11 77 31 87 00 10 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 77 31 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 40: 44 00 f8 0b 00 00 00 00 0c 20 00 00 04 00 0a 08 50: 81 1d 09 00 00 20 22 20 43 80 00 00 00 00 f0 40 60: 00 00 00 00 00 00 02 04 00 00 00 00 00 00 00 00 70: 06 11 77 31 00 00 00 00 00 00 00 00 20 00 00 00 80: 20 84 59 00 ba 10 00 00 01 40 00 00 da 10 00 00 90: 00 4a 00 88 a0 40 03 00 00 b7 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 01 50 01 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 04 08 02 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 Thanks a lot, Andreas Mohr - 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: HPET force-enable investigations on Via VT8235
Hi, On Tue, Aug 07, 2007 at 10:36:59AM +0200, Rafa?? Bilski wrote: > >RB> VT8235 does *NOT* have a HPET(*). Only part which has HPET is VT8237. > >It > >RB> is device 00:17.0 too, but only 1106:3227 has HPET enable and memory > >RB> base registers. VT8235 one and only feature which doesn't have driver > >RB> yet seems to be hardware watchdog. > >RB> (*) Datasheet revision 2.03 March 16, 2005 > > > >We have an Asrock K7VT4A+ board with VT8235 southbridge in our lab and it > >does have an HPET. Just because the datasheet does not document HPET does > >not mean it is not implemented. > > > >My guess is that newer revisions of VT8235 have HPET whereas older > >revisions > >do not. I'll get an lspci dump from our box tomorrow. > Indeed datasheet lies. I have VIA EPIA M1 Rev. B motherboard. Many datasheets are incorrect and don't follow realities of chipset design evolution. Which is why I started this quest in the first place ;) > % dmesg | grep -i hpet > Force enabled HPET at base address 0xfed0 > hpet clockevent registered > hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 > hpet0: 3 32-bit timers, 14318180 Hz > Time: hpet clocksource has been installed. Lucky bastard! :) > 00: 06 11 77 31 87 00 10 02 00 00 01 06 00 00 80 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 01 aa > 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 > 40: 45 00 f0 00 00 00 00 00 0c 20 00 00 44 00 0a 08 > 50: 81 1d 09 00 00 b0 a5 30 03 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 04 80 00 d0 fe 00 00 00 00 > 70: 06 11 01 aa 00 00 00 00 00 00 00 00 20 00 00 00 > 80: 20 84 59 00 b2 30 00 00 01 04 00 00 00 18 00 00 > 90: 00 1f 50 88 b0 c0 00 00 00 97 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 01 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 14 88 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 16 00 00 00 00 00 01 00 00 00 Thanks a lot! I'll do a diff on this versus the "non-working" dumps and have a peek at the VT8235/VT8237 datasheet to see whether there can something be done about it. I still don't entirely buy the "different chipset revision" theory, hopefully I'm correct and it's just another bit to tweak (but hopefully it's not a "write-only" bit that needs tweaking...). BTW, is there any obvious chipset ecosystem difference in your system? Are any other important PCI IDs/revs different from mine? Further working/non-working dumps greatly appreciated! Andreas Mohr - 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: HPET force-enable investigations on Via VT8235
0 00 00 00 00 00 00 *RB f0: 00 00 00 00 00 00 16 00 00 00 00 00 01 00 00 00 *US f0: 00 00 00 00 00 00 16 00 00 00 00 00 01 00 00 00 == hmm, 0xf6 bit 4/1 or 0xfc bit 0? == 0xf6 is not modifiable, but 0xfc is, but HPET still cannot be enabled Oh, my i815E P3 notebook (== ICH2, 8086:244c) does NOT allow me to enable HPET either, the corresponding bit (on 0xD2, IIRC) does not stick (since ICH3 is said to be the first chipset to enjoy force-enable support, and I wanted to verify this). About SiS support... SiS 964 is said to contain HPET support, so possibly 963, 962, ... secretly have it, too? Some of those might need some force-enabling as well... I don't have any such machines, though, only a rotten SiS 735 board ;) (the well-known K7S5A). Andreas Mohr - 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: Gericom Webboy Laptop Mouse/Touchpad
Hi, On Tue, Jul 31, 2007 at 09:54:03PM +0200, Daniel Mierswa wrote: > > Hi there, > i'm having troubles getting my mouse and/or touchpad to work with > 2.6.21.5 (and older ones). It's putting the following line into dmesg > everytime the laptop gets lots of I/O or cpu load. > "psmouse.c: Wheel Mouse at isa0060/serio4/input0 lost synchronization, > throwing 2 bytes away." This message is a wee bit too familiar to me as well, albeit for reasons different to that, I believe. :-$ > The problem still exists and seems to occur as i've mentioned on lots of > disk i/o and/or cpu load. > This is a laptop which is not supported by the manufactur anymore (seems > to be a Gericom Webboy). I would appreciate any tips to debug this further. > Please post back for any additional information you need. Hmm, I'm pondering what I'd do here... Could it be that you're using the "old" IDE layer (not libata yet) and hdparm -u or -d or -c is inconveniently set up? Maybe run powertop to identify timer anomalies? Try configuring a different CONFIG_HZ? Or maybe run oprofile to try to figure out any abnormal system load? And did you try running a "barebone"-only configuration? Possibly some certain driver is causing this misbehaviour... vmstat may provide some initial information as to what kind of activity exactly causes this issue. Or maybe it's a simple X.org scheduling issue again? What nice value do you run X.org at? If it's too low, then maybe this causes the psmouse.c driver to have its mouse queue(?) processing get stuck and makes it have a hickup? In this context it would be good to ask about possible memory pressure on this system, too, since recently some people indicated more fluid X.org mouse pointer operation when mlocking the pointer handling code to avoid paging this code. Oh, given that IIRC the Webboy is a slightly older Gericom model which thus may easily be a (somewhat hotter) P4 *desktop* CPU: could it be that you're hitting thermal emergency throttling on increased system activity? cat /proc/acpi/processor/*/throttling or something there might indicate this. HTH, Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] eradicate bashisms in scripts/patch-kernel
Hi,
On Fri, Nov 02, 2007 at 10:01:18AM +0800, Herbert Xu wrote:
> On Thu, Nov 01, 2007 at 04:08:57PM -0700, Randy Dunlap wrote:
> > I think that this is the part that bothers me. I can't find
> > anything at
> > http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html
> > that says that this:
> > EXTRAVER=${EXTRAVER%%[[:punct:]]*}
> >
> > is invalid or even optional syntax. OTOH, it does list such syntax,
>
> This is POSIX-compliant and has worked with dash from the very
> start.
True (just verified again). But then I didn't actually say that this line
is problematic. Since I had to replace the leading . replacement part already
I decided to simply fold everything into one sed expression.
> Using variables without dollar signs in arithmetic expansion was
> only added to dash very recently. So please please talk to your
> distribution maker to update their dash packages and it will work
> correctly.
"Debian stable.", aka "Update not an option.". Right?
Since the specs list both possibilities I'd simply go with the safe one,
the one that works on older dash versions, too.
Unless adding a $ sign happens to break other equally important
shells...
> This usage is compliant with the most recent revision of POSIX
> while earlier ones did not specifically require this (due to
> the fact that assignment support was not required either).
This is where I'd think the problem is. If dash once upon a time
decided to support the $ variant only and the specs didn't list both
at that time, well...
The dash version on my system is 0.5.3-5, BTW. Even Debian testing
has 0.5.3-7 only.
I'm now quite certain on which side to tweak things ;)
Thanks a lot for your review,
Andreas Mohr
-
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: VIA VT6307 OHCI version?
Hi, On Sun, Oct 28, 2007 at 09:40:41PM +0100, Krzysztof Halasa wrote: > Stefan Richter <[EMAIL PROTECTED]> writes: > > >> Compile with the usual spell: gcc -Wall -O2 vt6307ohciver.c -o > >> vt6307ohciver > > > > I also had to specify "-lpci" on Mandrake 10.1, "-lpci -lz" on Gentoo. > > Of course you're right, just typed faster than thought. > Actually I had to add these two on Fedora, too. And in general the pciutils-dev package should be installed. > Ok so it seems rev 80 is VT6307 and (at least) rev 46 is VT6306. > I think my googling for lspci reports confirms that. As does my card: # lspci |grep 1394 00:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) [EMAIL PROTECTED]:/tmp# ./vt6307ohciver 00:09.0 I/O region #1 is at A000 It seems your VT6307 chip is connected to 93c46 EEPROM Page size is 4096 (0x1000) bytes GUID PROM register address is 0xdb140004 Mapping 8 (0x8) bytes of memory at 0xdb14 Mapped mem region #0 at virtual address 0xb7ee5000 GUID PROM register is at virtual address 0xb7ee5004 EEPROM dump: 00: 00 11 06 66 45 55 56 E1 04 04 32 55 F8 00 A2 02 10: A1 00 40 63 06 11 44 30 03 DF 40 80 00 20 00 73 20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF Your VT6307 chip is in OHCI 1.0 mode And viewing from a quite problematic angle (card is in running PC, difficult to view) strongly seems to indicate a VT630_6_ (the "6" is quite clearly visible). This means that I currently cannot offer any mfct. date data however, unfortunately. Andreas Mohr - 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: VIA VT6307 OHCI version?
Hi, On Mon, Nov 05, 2007 at 12:00:16AM +0100, Krzysztof Halasa wrote: > Andreas Mohr <[EMAIL PROTECTED]> writes: > > And viewing from a quite problematic angle (card is in running PC, > > difficult to view) strongly seems to indicate a VT630_6_ (the "6" is > > quite clearly visible). > > This means that I currently cannot offer any mfct. date data however, > > unfortunately. > > Yeah. I think (feel or something) VIA does the usual thing with > revision numbers so rev 0x46 means always the same silicon (VT6306) > and rev 0x80 is always the same VT6307. There might be other > revisions but I think we won't find non-VT6306 rev 0x46 or > non-VT6307 rev 0x80. OK, PC was off now (good to be using S2D instead of S2R ;), the card data is: "SN1394", "STARNET V1.0" mfct.: 0450 VIA VT6306 0449CD TAIWAN 2HG1002703 (IOW, a moderately new VT6306 card) SEEPROM: ATMEL 418 93C46 PI27 A I'm only an occasional Firewire user (external backup HDD, miniDV grabbing), but I'm very thankful for your nice investigations! Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] eradicate bashisms in scripts/patch-kernel
Hi, On Fri, Nov 02, 2007 at 01:17:07PM -0700, Randy Dunlap wrote: > On Fri, 2 Nov 2007 21:09:35 +0100 Andreas Mohr wrote: > > > Hi, > > > I'm now quite certain on which side to tweak things ;) > > The other parts of your patch should probably be merged IMO. Hmm, that particular part consists of _two_ transformations: - removing the leading dot - keep everything before [:punct:] and the first transformation doesn't work on certain dash versions the way it's currently coded. > Would you resend a trimmed-down patch? > or should I do it? Feel free to go ahead, otherwise I'll try another patch sometime soon. All I care about is that the result works on (at least) one shell implementation _more_ than the current status ;) Thanks a lot, Andreas Mohr - 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: prioritize PCI traffic ?
Hi, On Mon, Jan 15, 2007 at 12:07:45PM +0100, Soeren Sonnenburg wrote: > Dear all, > > is it possible to explicitly tell the kernel to prioritize PCI traffic > for a number of cards in pci slots x,y,z ? > > I am asking as severe ide traffic causes lost frames when watching TV > using 2 DVB cards + vdr... This is simply due to the fact that the PCI > bus is saturated... > > So, is any prioritizing of the PCI bus possible ? You probably need to adjust PCI latency settings via setpci: http://www-128.ibm.com/developerworks/library/l-hw2.html Not sure whether this is a LKML related question ;) Andreas Mohr - 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.20-rc5: usb mouse breaks suspend to ram
Hi, On Tue, Jan 16, 2007 at 04:25:20PM -0500, Dmitry Torokhov wrote: > No, HID is the preferred... I am not sure what is going on - on my box > STR does not work at all thanks to nvidia chip turning the display on > all the way as the very last step of suspend ;( One or several of these options might help cure this: - agp=off kernel command line (plus AGP driver option enabled in nvidia xorg.conf) - suspend: cat /proc/bus/pci/AA/BB.C >/tmp/video_state--> resume - suspend: vbetool vbestate save--> resume - directly after resume: vbetool post - playing with chvt to not stay in X vt upon suspend - acpi_sleep=s3_bios or acpi_sleep=s3_mode Especially the PCI video_state trick finally got me a working resume on 2.6.19-ck2 r128 Rage Mobility M4 AGP *WITH*(!) fully enabled and working (and keeping working!) DRI (3D). Or, to be precise, video_state was the ticket to keeping X.org alive after resume instead of near-100% X lockup, which then allowed vbestate post to successfully deal with the remaining pixel line distortion in order to get a clear display again. And some agp hacks might have played a role here, too, need to investigate this again and submit something if this is the case. In your case this sounds like the all-too-familiar mis-signalling of the TFT display causing it to "melt" which ends up with an all-white screen, so this should most likely be cured via vbetool post or so. keywords: agpgart r128 suspend resume vbetool intel-agp dri Andreas Mohr - 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/
intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
Hi, On Wed, Jan 17, 2007 at 01:57:55AM +0100, Pavel Machek wrote: > > Especially the PCI video_state trick finally got me a working resume on > > 2.6.19-ck2 r128 Rage Mobility M4 AGP *WITH*(!) fully enabled and working > > (and keeping working!) DRI (3D). > > Can we get whitelist entry for suspend.sf.net? s2ram from there can do > all the tricks you described, one letter per trick :-). We even got > PCI saving lately. Whitelist? Let me blacklist it all the way to Timbuktu instead! I've been doing more testing, and X never managed to come back to working state without some of my couple intel-agp changes: - a proper suspend method, doing a proper pci_save_state() or improved equivalent - a missing resume check for my i815 chipset - global cache flush in _configure - restoring AGP bridge PCI config space The remaining suspects (the other hacks alone didn't recover it) are global cache flush and restoring of the *entire* AGP bridge PCI config space (no, a 64-bytes-only pci_restore_state() alone doesn't help, and it didn't help either that intel-agp doesn't do pci_save_state() anywhere - unless that's now done by default by PCI layer). I'll do more testing today to isolate which change exactly fixed it. All in all intel-agp code semi-shattered my universe. I didn't expect to find all these issues in rather important core code for a wide-spread chipset vendor - it doesn't even log an "unhandled chipset: resuming may fail, please report!" message in the resume handler in case of a missing chipset check (although it may be debatable whether people are able to see this message at all). However since the new AGP code was a heroic refactoring effort it's understandable that there are some remaining issues. Given the myriads of resume issues we experience in general, it may be wise to do something as simple as a code review of *all* relevant code no matter how "complete" we expect each driver to be... (one could e.g. start with reviewing all other AGP chipset drivers). Andreas Mohr - 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: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]
Hi,
On Thu, Feb 22, 2007 at 10:07:19PM +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> > no; c3 saves a TON more power.
> >
> > you can try enabling HPET in your BIOS...
> >
> >
>
> Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
> as is humanly possible.
>
> Can I determine if I have the required hardware? So I can tell if I'm
> permanently screwed, or just temporarily.
http://lkml.org/lkml/2006/11/14/153
and related posts in this older thread
("CONFIG_NO_HZ: missed ticks, stall (keyb IRQ required) [2.6.18-rc4-mm1]")
should help.
Andreas Mohr
-
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.20-mm2 CONFIG_ACPI_BAY=y: undefined reference to `is_dock_device'
Hello all, make-kpkg kernel_image bombed with: LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `bay_is_dock_device': drivers/acpi/bay.c:261: undefined reference to `is_dock_device' drivers/acpi/bay.c:261: undefined reference to `is_dock_device' drivers/built-in.o: In function `bay_add': drivers/acpi/bay.c:308: undefined reference to `register_hotplug_dock_device' drivers/built-in.o: In function `bay_exit': drivers/acpi/bay.c:384: undefined reference to `is_dock_device' drivers/acpi/bay.c:385: undefined reference to `unregister_hotplug_dock_device' make[1]: *** [.tmp_vmlinux1] Error 1 make[1]: Leaving directory `/usr/src/linux-2.6.20-mm2' Famous last words: CONFIG_ACPI_DOCK=m... Andreas Mohr - 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: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
Hi,
On Mon, Jan 22, 2007 at 12:45:19PM +0800, Wang Zhenyu wrote:
> I've post a patch which trys to resolve pci config restore issue, see
> http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine,
> that my X can come back to live after s3, but I wasn't aware of the issues
> Andreas
> has noted. It'll be good if more people could try this out.
[sorry, somewhat late, had complete and utter heating failure at home]
I employed a variant of your patch (added a static i815_dev
to support my i815 chipset). It didn't help, X hung on resume.
PCI IDs of i815 are 0x1130, 0x1131, 0x1132.
I'm having 0x1130 and 0x1131, IOW an i815 system in
"external AGP graphics" mode:
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory
Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 02)
so I need to query 0x1131 instead of PCI_DEVICE_ID_INTEL_82815_CGC
(0x1132) for resume of the proper device, right??
Or am I supposed to restore the PCI space of my *non-builtin*
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M4 AGP
card instead?
The diff below (against 2.6.19-ck2 or in fact plain 2.6.19)
shows what I changed from my (working!) version to what I think I
had to do to be compatible with your intentions. OK, not quite,
I now merely disabled the suspend/restore of the full PCI space,
several other parts remained the same.
IOW, suspending/restoring the *full* PCI space of my Host Bridge
helped, whereas restoring the standard PCI space of my Host Bridge
plus restoring the PCI space of the AGP bridge as you suggested
did NOT.
Can we conclude from that that I'm having rather different issues
than you?
I think this means that we are required/supposed to backup
the entire PCI space of host bridges, right? How to actually implement
this cleanly? Oh, and of course my patch manages to fix the X11
lockup only, actual video is still garbled and requires
vbetool magic to get it fixed, too...
Thanks,
Andreas Mohr
--- intel-agp.c 2007-02-07 21:50:49.0 +0100
+++ intel-agp.c.2619ck2.patched 2007-02-07 21:50:04.0 +0100
@@ -1666,6 +1666,9 @@
return 1;
}
+static struct pci_dev *i815_dev;
+
+
static int __devinit agp_intel_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -1719,7 +1722,10 @@
if (find_i810(PCI_DEVICE_ID_INTEL_82815_CGC))
bridge->driver = &intel_810_driver;
else
+ {
+ i815_dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x1131,
NULL);
bridge->driver = &intel_815_driver;
+ }
name = "i815";
break;
case PCI_DEVICE_ID_INTEL_82820_HB:
@@ -1921,12 +1927,62 @@
}
#ifdef CONFIG_PM
+
+#if 0
+static u32 pci_cfg_space[64];
+
+static int agp_intel_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ int i;
+ for (i = 0; i <= 63; i++)
+ pci_read_config_dword(pdev, i * 4, &pci_cfg_space[i]);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+
+ printk(KERN_INFO "agp_intel_suspend\n");
+
+ return 0;
+}
+#endif
+
static int agp_intel_resume(struct pci_dev *pdev)
{
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
+ int i;
+ int val;
+ pci_set_power_state (pdev, PCI_D0);
pci_restore_state(pdev);
+ if (i815_dev)
+ pci_restore_state(i815_dev);
+
+#if 0
+ for (i = 15; i >= 0; i--) {
+ pci_read_config_dword(pdev, i * 4, &val);
+ if (val != pci_cfg_space[i]) {
+ printk(KERN_DEBUG "AGP: Writing back config space on "
+ "device %s at offset %x (was %x, writing %x)\n",
+ pci_name(pdev), i,
+ val, pci_cfg_space[i]);
+ pci_write_config_dword(pdev, i * 4,
+ pci_cfg_space[i]);
+ }
+ }
+ for (i = 63; i >= 16; i--) {
+ pci_read_config_dword(pdev, i * 4, &val);
+ if (val != pci_cfg_space[i]) {
+ printk(KERN_DEBUG "AGP: Writing back config space on "
+ "device %s at offset %x (was %x, writing %x)\n",
+ pci_name(pdev), i,
+ val, pci_cfg_space[i]);
+ pci_write_config_dword(pdev, i * 4,
+ pci_cfg_space[i]);
+ }
+ }
+#endif
+
+ printk(KERN_INFO "agp bridge is %04x\n", agp_bridge->dev->device);
+
if (bridge->driver == &intel_generic_driver)
intel_configur
