| === rikai__ is now known as rikai | ||
| _MMA_ | BenC: Are the links abogani (Alessio) posted in the email (wrt -rt) sufficient for your request? | 14:14 |
|---|---|---|
| BenC | _MMA_: I'm already working on it | 14:16 |
| * _MMA_ hugs Ben. I owe you many beers. | 14:16 | |
| Ng | rtg: did you get anything useful back from Intel? | 14:29 |
| rtg | Ng: stonewalling. | 14:30 |
| rtg | Jesse has not proposed a solution. I think they are still trying to repro the corruption. | 14:30 |
| Ng | rtg: do you know what's stored in the EEPROM that we might ever actually want to write to? | 14:34 |
| Ng | I don't know when the freezes for us/kernel.org are, but I'm really concerned that this will sneak into releases | 14:34 |
| rtg | Ng: I think there must be an ASIC on the card, or perhaps a CPU, because the firmware is necessary in order for the PCI scan to work. | 14:35 |
| rtg | Ng: Its already in releases. This issue goes back to the initial incarnation of e1000. | 14:35 |
| rtg | Ng: for some reason, its just starting to show up more often. | 14:35 |
| Ng | rtg: ah right | 14:35 |
| Ng | rtg: what I'm wondering is if we actually need the write support | 14:36 |
| Ng | I don't know what's stored in there, but if we don't change it in normal operation, why keep it around and risk further damage? :) | 14:36 |
| rtg | Ng: I'm watching the netdev mailling list. If I have not seen any more activity on it by Monday, I'll stir the pot. | 14:37 |
| Ng | ok | 14:37 |
| rtg | Ng: what I don't understand is how flash could be getting corrupted by oops in the kernel. Even if that memory space is cribbled on, flash requires command to setup for writes. Its not as simple as just writing some values. there is a whole flash update protocol required by the hardware. | 14:38 |
| Ng | rtg: what would normally cause that update protocol to be used? | 14:45 |
| Ng | is it just ethtool operations? | 14:45 |
| rtg | Ng: pretty much. It requires intervention by an operator. changing flash is not something that is normally done, except when updating firmware. | 14:46 |
| Ng | could it be something like network-manager tickling it when it switches networks? like if it sets some properties on the device maybe? | 14:46 |
| Ng | if nothing else they should surely put in something which logs flash writes, so they might at least be able to figure out what is doing it? | 14:47 |
| rtg | Ng: seems unlikely. Your bug report indicated that you were not doing anything special wrt networking, correct? | 14:47 |
| Ng | rtg: not that I was aware of | 14:48 |
| Ng | but Nm0.7 does have much deeper options for network interfaces, like setting MACs and so on | 14:48 |
| rtg | Ng: it also takes CAP_ADMIN provs to write flash, which NM does not have. | 14:48 |
| Ng | hmm | 14:48 |
| Ng | I guess that ethtool stuff makes it a bit unreasonable to make the flash part read-only :/ | 14:50 |
| amitk | BenC: ok with you if I update aufs to the latest? | 14:51 |
| rtg | Ng: the vmware guys think its an exclusion/locking issue, but I'm not convinced. the ICH8 has a hardware method for locking that (unless the HW is broken) look fool proof. | 14:51 |
| BenC | amitk: hell yeah | 15:06 |
| * BenC hates messing with aufs | 15:06 | |
| Ng | rtg: yeah I saw the rubbishing of their patch | 15:07 |
| Ng | rtg: if they'd just make it possible to dump/restore the thing I'd be happy to start peppering the driver with printk()s so if it happens again I'd have more info | 15:10 |
| Ng | as it is I think I'm going to have to disable the NIC in the BIOS and remove e1000*.ko | 15:11 |
| rtg | Ng: you use mostly wireless anyway? Disabling the e1000e is probably a good idea until the corruption issue gets sorted out. | 15:14 |
| Ng | rtg: I prefer to use wired in the office, but I can live without it | 15:14 |
| rtg | Ng: you could always use an external USB ethernet | 15:15 |
| Ng | yeah | 15:16 |
| Ng | rtg: can you think of anything other than ethtool which would even be likely to try and trigger the writes? | 15:20 |
| rtg | Ng: honestly, I think flash writes is a red herring. I'm wondering if there is a more prosaic reason, like some hardware issue with the part. | 15:25 |
| rtg | Ng: but, no, ethtool should be the only thing capable of writing to flash. | 15:26 |
| Ng | NM looks like it at least reads ethtool info from an ioctl | 15:27 |
| rtg | mdomsch: I'm starting to get the hang of this DKMS stuff. I'm gonna use it to replace build madwifi from the madwifi-hal-2008-08-15 branch which has support for newer Atheros parts. | 16:11 |
| mdomsch | rtg, sweet | 16:12 |
| mdomsch | thanks for the +1 on mario's app for core-dev too | 16:12 |
| rtg | mdomsch: np. he deserves it. | 16:13 |
| mkrufky | where can i find the licenses for the firmware images shipped in /lib/firmware/`uname -r`/ ? | 16:37 |
| rtg | mkrufky: probably somewhere in /usr/share. I think its a debian policy thing | 16:38 |
| mkrufky | thanks, rtg | 16:40 |
| mkrufky | actually, rtg, i dont see a way here to find out the license associated to a particular firmware file | 16:42 |
| rtg | are they all jammed together in file? | 16:43 |
| mkrufky | dvb-usb-dib0700-1.10.fw | 16:43 |
| mkrufky | well, i dont even see anything that deals with firmware license at all | 16:43 |
| mkrufky | that doesnt mean its not there... i just dont see it ;-) | 16:43 |
| rtg | mkrufky: is this LRM ? I can't remember what package that FW comes from. | 16:44 |
| mkrufky | i dont think so... i think it came with the default kernel | 16:44 |
| mkrufky | its on every fresh install of ubuntu | 16:44 |
| mkrufky | its *in* ^^ | 16:44 |
| rtg | mkrufky: Hardy? | 16:44 |
| mkrufky | hardy, yes | 16:45 |
| mkrufky | i didnt go back to look at dapper / hoary. fiesty | 16:45 |
| rtg | mkrufky: its installed from the LRM package. perhaps BenC would know. he's more up on debian policies than am I. | 16:48 |
| mkrufky | ah, okay | 16:49 |
| BenC | mkrufky: if it's from the default kernel, then it's in the kernel source tree...or in git-log's | 17:01 |
| mkrufky | hmm | 17:01 |
| mkrufky | ok, i'll search git | 17:02 |
| mkrufky | thanks, BenC and rtg | 17:02 |
| sioux | who know if spca561a module is available by default on next intrepid kernel? | 17:25 |
| === mkrufky is now known as mkrufky-away | ||
| rtg | mdomsch: how do I prevent LRM from installing new madwifi binaries on the next minor version update? Or rather, how do I get the DKMS package to trigger a rebuild such that it stashes the new LRM kernel modules and replaces them with the DKMS modules? | 17:59 |
| mdomsch | hmm | 18:00 |
| mdomsch | where did LRM put its copy? | 18:00 |
| rtg | madwifi/ath_pci.ko | 18:00 |
| rtg | and volatile/ath_hal.ko | 18:01 |
| mdomsch | is the MODULE_VERSION() in there < the one in the DKMS database? | 18:01 |
| rtg | I just refresh trhe LRM package, so the version didn't change. I downloaded the deb and 'dpkg -i blah...' | 18:02 |
| mdomsch | right | 18:02 |
| mdomsch | well, here's how it works | 18:02 |
| mdomsch | you dkms install a new package | 18:03 |
| mdomsch | it drops its result in to /lib/modules/$kernelver/extra/ | 18:03 |
| mdomsch | if LRM drops a new package elsewhere in the tree | 18:03 |
| mdomsch | it'll get ignored as long as /extra/ is in the modprobe search path earlier than drivers/ | 18:04 |
| mdomsch | which it should be | 18:04 |
| rtg | I've been dropping the DKMS bits in /updates. I'll try putting them in /extras | 18:04 |
| mdomsch | rtg, whichever, doesn't matter | 18:05 |
| mdomsch | as long as it's in the search path before where LRM puts it | 18:05 |
| rtg | mdomsch: another problem I forsee is if I remove the DKMS package. Its gonna restore the stashed copies of the LRM modules to the version prior to this most recent LRM update. | 18:06 |
| mdomsch | yes | 18:07 |
| rtg | ok, I just need to be aware of the caveats. | 18:07 |
| * mdomsch hated the whole 'stash a copy' thing | 18:07 | |
| mdomsch | but we didn't have a search path in modprobe at the time | 18:08 |
| rtg | mdis there a way to disable the stash thing? | 18:08 |
| rtg | mdomsch: ^^ | 18:08 |
| mdomsch | not that I can think of | 18:08 |
| mdomsch | at present | 18:08 |
| rtg | mdomsch: it would be a useful feature in this case. | 18:09 |
| rtg | mdomsch: hmm, I changed to dkms.conf:DEST_MODULE_LOCATION[0]="/extras/madwifi-hal-2008-08-15", but the bits are still getting put in /updates. I extracted the package on the target machine and looked at its dkms.conf just to be sure. | 18:25 |
| mdomsch | rtg, yeah | 18:25 |
| mdomsch | that value is just advisory anymore | 18:25 |
| mdomsch | it gets overridden when various other bits are present | 18:25 |
| rtg | mdomsch: oh, I was using your OLS paper example. | 18:26 |
| mdomsch | rtg, that's somewhat outdate too :-) | 18:26 |
| mdomsch | it's mostly right though | 18:26 |
| mdomsch | on Ubuntu, DKMS installs into /updates/dkms/ | 18:27 |
| mdomsch | there's a distro-version check to override DEST_MODULE_LOCATION | 18:27 |
| mdomsch | function override_dest_module_location() | 18:27 |
| rtg | mdomsch: ok, I'll muck about and see what I can wreck. | 18:28 |
| mdomsch | it is also configurable by setting addon-modules-dir=something/ in /etc/sysconfig/module-init-tools | 18:29 |
| mdomsch | or ADDON_MODULES_DIR in the environment calling DKMS | 18:29 |
| === mkrufky-away is now known as mkrufky | ||
| rtg | mdomsch: alright, this is pretty cool. I think I've got a solution for all of the Atheros advanced chipset crackheads. | 19:02 |
| mdomsch | oh? | 19:03 |
| rtg | I especially like how DKMS rebuilds itself when I booted to a different ABI. | 19:03 |
| mdomsch | it should rebuild when you install a new kernel with a new ABI too | 19:04 |
| mdomsch | before reboot | 19:04 |
| rtg | mdomsch: right, but I wanted to make sure booting to an older kernel also worked. | 19:04 |
| mdomsch | ah, yes | 19:04 |
| rtg | mdomsch: anyway, kudos. its a great package. | 19:05 |
| mdomsch | glad it's useful to you | 19:05 |
| mdomsch | and I'm glad to see it's wide use in Ubuntu | 19:05 |
| * mdomsch nods to superm1 for that | 19:05 | |
| mdomsch | he's the official maintainer now too | 19:05 |
| rtg | mdomsch: Mario is actually whom I'm doing this for. | 19:06 |
| === _Nicke_ is now known as Nicke | ||
| CarlFK | smb_tp: just say your note - about to try, so don't go home yet :) | 23:54 |
| smb_tp | CarlFK, I am home. Not working very much longer but I'll wait for you to try. ;-) | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!