| Kamping_Kaiser | ah goody. bug 292381 . Ill suscribe myself | 00:38 |
|---|---|---|
| ubot3 | Malone bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,In progress] https://launchpad.net/bugs/292381 | 00:38 |
| Quintasan | Can anyone tell me will the ext4 fix (scheduled to release with 2.6.30) will be backported to Ubuntu kernel? | 12:27 |
| rtg | Quintasan: Jaunty is following stable updates wrt ext4 | 12:36 |
| Quintasan | wrt? | 12:37 |
| rtg | Quintasan: 'with respect to' | 12:42 |
| dandel | rtg, did the 2.6.25 kernel build mess up or something? | 12:42 |
| dandel | it's completely unbootable on 1 of my boxes. | 12:43 |
| rtg | dandel: I only received notification that it built. Have to tried 2.6.26 as well? | 12:44 |
| amitk_ | dandel: it is an automated build | 12:44 |
| dandel | i have tried 2.6.25 and 2.6.26 against bug #338701 | 12:44 |
| ubot3 | Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701 | 12:44 |
| dandel | 2.6.26 and 2.6.27 both have the same error | 12:44 |
| dandel | as for 2.6.25 i put the exact stop point up on the bug report | 12:45 |
| dandel | it appears that the start_secondary integration might of been what knocked out my acpi. | 12:47 |
| rtg | amitk_: so, you don't like that VFP patch, huh? | 12:54 |
| amitk_ | amitk_: 1 down, 1 to go :) | 12:57 |
| Quintasan | rtg: thanks | 12:57 |
| amitk_ | rtg: The remaining one has been around for over a year. I don't like applying patches that upstream might have rejected | 12:57 |
| Kano | hi rtg | 13:22 |
| Kano | rtg: did you read my mail about hpa | 13:22 |
| rtg | Kano: just working through the list. I was traveling yesterday | 13:23 |
| Kano | rtg: could you revert the hpa change? | 14:17 |
| Kano | i can do that for my kernel packages, but i dont want to have offline members of my raid when i test u | 14:17 |
| Kano | http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=0d3c04214230d4340345a7a5d5353883b3299d9f | 14:19 |
| Kano | revert this please | 14:19 |
| soren | Kano: What's the problem with it? | 14:26 |
| Kano | the problem is that i have got hds with hpa which are raid members (using dmraid) | 14:27 |
| Kano | if hpa is unlocked it is not working. another problems war boards which store bios backup information | 14:28 |
| Kano | at the end of a hd | 14:28 |
| Kano | then that hd is locked by hpa and it should not be overritten | 14:28 |
| Kano | this is known for some new gigabyte boards | 14:29 |
| Kano | i wrote the same to the mailinglist | 14:29 |
| Kano | that feature is called virtual dual bios | 14:32 |
| soren | Kano: Wouldn't the same problem happen to people who are used to having hpa disabled by default, then? | 14:42 |
| Kano | soren: dmesg|grep HPA | 14:42 |
| Kano | no output -> no error | 14:42 |
| soren | Eh? | 14:43 |
| Kano | soren: most systems do not use hpa | 14:44 |
| soren | If someone is used to having HPA disabled and have RAID members configured like that, and we suddenly don't disable it by default anymore, /they/ are going to be screwed, aren't they? | 14:44 |
| Kano | soren: the motherboard raid seems to rely on it | 14:45 |
| Kano | it is impossible that you have to unlock it. windows does not unlock hpa | 14:45 |
| Kano | only 1 user even had issues from disabling hpa and that was definitely his own fault | 14:46 |
| Kano | because he used the 32 gbit limit jumper. he did not do that by purse, i guess he just looked at the jumper picture the wrong way | 14:47 |
| Kano | thats a very clear error then, when fdisk -l reports a 32 gb partition only | 14:48 |
| Kano | ata2.00: HPA detected: current 66055248, native 312581808 | 14:49 |
| Kano | thats how it looks | 14:49 |
| soren | How is it impossible that I have to unlock it? I've most certainly had systems before where the BIOS wanted me to not see parts of the hard drive and had the kernel fix that up for me. | 14:49 |
| Kano | in dmesg | 14:49 |
| Kano | soren: you can still force it,but do not disable hpa by default | 14:49 |
| soren | Correct me if I'm wrong, but disabling HPA has been the default in Ubuntu for a long time, hasn't it? | 14:50 |
| Kano | it was default for 8.04 | 14:51 |
| Kano | but not for 8.10 | 14:51 |
| rtg | soren: /etc/modprobe.d/options:options libata ignore_hpa=1 | 14:51 |
| Kano | maybe in the options, but i do not use those options | 14:51 |
| Kano | but if that was the option, then the override would be libata.ignore_hpa=1 if somebody needs it | 14:51 |
| soren | Kano: Well, pardon me, but how are your defaults our problem? | 14:52 |
| rtg | Kano: so, Jaunty behavior has not changed. we removed the modprobe option and made ignore_hpa=1 the default in the module. | 14:52 |
| Kano | rtg: it is still the wrong. the kernel default is better | 14:53 |
| rtg | Kano: feel free to add the option to your modprobe options | 14:53 |
| Kano | they do not matter when you statically build it | 14:53 |
| rtg | grub is your friend | 14:54 |
| soren | Kano: That really depends on how you define "better". | 14:55 |
| Kano | soren: i define it less problematic. if you have got a raid and when you boot linux and then you see all are offline members, then you can get panic | 14:56 |
| Kano | only full power off works | 14:56 |
| soren | Kano: Yes, but if you installed your system with ignore_hpa=1 and it's suddenly =0, then you have the same problem. | 14:57 |
| Kano | soren: only in the case that hpa was used! thats a very rare case | 14:57 |
| soren | ...and since we've had ignore_hpa=1 for a while now, sticking with that will cause least problems for /our/ users. | 14:57 |
| Kano | not correct | 14:57 |
| Kano | it will force problems for NEW users | 14:58 |
| Kano | with gigabyte boards | 14:58 |
| * soren finds something else to do... | 14:58 | |
| soren | It's not my decision anyway. | 14:58 |
| * Daviey wonders what LTS -> LTS upgrade will bring | 15:01 | |
| rtg | Daviey: IIRC, ignoring HPA has been the default since Feisty | 15:03 |
| Daviey | Oh | 15:03 |
| Daviey | < Kano> it was default for 8.04 <-- confused me | 15:03 |
| Kano | soren: what do you win when you unlock hpa, next time the bios writes its backup again there an then data of the last partition at the end is overwitten | 15:03 |
| rtg | Daviey: can't tell you how we'll handle Dapper upgrades | 15:03 |
| Kano | Daviey: it was a kernel config setting for hdX devices (legacy code), but now ide legacy is not used anymore | 15:04 |
| johanbr | anubhav: Changing up_threshold for the ondemand governor made a big difference. Thanks! | 16:04 |
| anubhav | johanbr:cool :) | 16:04 |
| johanbr | For the Ubuntu kernel devs: up_threshold for the ondemand governor was set to 60 in Intrepid, but in Jaunty it's 95. | 16:07 |
| johanbr | This makes the ondemand governor very slow to trigger. What's the reason for this change? | 16:07 |
| anubhav | johanbr: laptops will run much cooler i guess | 16:10 |
| === amitk_ is now known as amitk | ||
| === mkrufky is now known as mkrufky-away | ||
| JanC | anubhav: shouldn't that be set depending on laptop vs. desktop then? | 17:04 |
| anubhav | amitk : For the Ubuntu kernel devs: up_threshold for the ondemand governor was set to 60 in Intrepid, but in Jaunty it's 95.This makes the ondemand governor very slow to trigger. What's the reason for this change? | 17:06 |
| anubhav | amitk: This question was asked by johanbr.Do you have any idea? | 17:07 |
| amitk | anubhav: I am not aware of the reason for the change. Is it different from the value that upstream uses? | 17:09 |
| rtg | amitk: it is the upstream code, but it changed a bit from Intrepid. | 17:09 |
| mjg59 | No, it's what upstream uses when you have microaccountin | 17:10 |
| anubhav | mjg59: By upstream do you mean the kernel? | 17:14 |
| rtg | anubhav: by upstream we mean Linus' repository | 17:16 |
| mjg59 | Yes | 17:18 |
| anubhav | so the driver by default sets to 95? | 17:18 |
| anubhav | let me check the code | 17:18 |
| mjg59 | MICRO_FREQUENCY_UP_THRESHOLD is the relevant define here | 17:20 |
| anubhav | yeah got it,but in the Documentation its mentioned that 80 is default | 17:21 |
| anubhav | http://lxr.linux.no/linux+v2.6.28.4/Documentation/cpu-freq/governors.txt | 17:22 |
| mjg59 | The documentation is out of date | 17:23 |
| mjg59 | It's 80 if you don't have support for idle microaccounting | 17:23 |
| mjg59 | Because there's less certainty about the true workload | 17:23 |
| === mkrufky-away is now known as mkrufky | ||
| Unggnu | hi all | 17:44 |
| Unggnu | How can I activate/use the Ubuntu kernel staging drivers? | 17:45 |
| Unggnu | like the ones listed under https://lists.ubuntu.com/archives/jaunty-changes/2009-January/003537.html | 17:53 |
| davygrvy | what are the kernel options to reserve irq 3, port range 210-21F and dma 1 ? | 20:50 |
| davygrvy | something I'll be running in dosemu will need them | 20:51 |
| mjg59 | Simply don't bind a driver to them | 20:54 |
| davygrvy | all that boot stuff is automatic | 20:56 |
| mjg59 | Which driver is taking them? | 20:56 |
| davygrvy | don't know yet, I want to be prepared | 20:57 |
| davygrvy | in the older hardware the pccard redirector took 3 | 20:57 |
| mjg59 | The kernel isn't responsible for IRQ routing. If there's hardware that's decoding that irq and io port ranges then simply getting the kernel to ignore them won't make things magically work for you | 20:58 |
| davygrvy | is there a how-to for irq, port, and dma conflicts? | 20:58 |
| davygrvy | some stuff is programmable, though. the pci video card could do three irqs | 21:01 |
| mjg59 | Programmable by the bios, yes | 21:01 |
| davygrvy | well, if this bios let me in :) but that's another story about old IBM thinkpad lame-o bios | 21:02 |
| mjg59 | What, precisely, are you trying to do? | 21:02 |
| davygrvy | what are the kernel options to reserve irq 3, port range 210-21F and dma 1 ? | 21:02 |
| mjg59 | That's not a useful question for you to ask | 21:02 |
| davygrvy | iow, disallow it being used | 21:02 |
| davygrvy | why? | 21:03 |
| mjg59 | Because dosemu isn't going to pay any attention to whether or not the kernel has allocated them anyway | 21:03 |
| mjg59 | Why are you trying to prevent them being used by the kernel? | 21:04 |
| davygrvy | because the specail ISA data aquisition card for this old DOS app uses them | 21:04 |
| mjg59 | Ok. | 21:07 |
| mjg59 | But the kernel doesn't allocate IRQs, the BIOS does. And if the BIOS gives IRQ 3 to something else then reserving it in the kernel won't help. | 21:08 |
| davygrvy | In that respect I see, but would be nice see a nice error message telling me that | 21:09 |
| davygrvy | I'm sorry, the port redirector for PCCards is on 3, can not continue.. or whatever | 21:09 |
| davygrvy | what are the kernel boot options to reserve irq 3, port range 210-21F and dma 1 ? | 21:10 |
| mjg59 | You can prevent the kernel using IRQ 3 for PCI by passing irqmask=0xfff7 | 21:11 |
| davygrvy | where is that mask documented? | 21:12 |
| mjg59 | Documentation/kernel-paramaters.txt | 21:12 |
| davygrvy | looks to be ~(0x0003) | 21:12 |
| davygrvy | ahh | 21:12 |
| davygrvy | that you | 21:12 |
| davygrvy | err | 21:12 |
| davygrvy | thank you | 21:12 |
| davygrvy | that took alot of words to get there | 21:13 |
| mjg59 | But that doesn't reserve irq 3 | 21:14 |
| mjg59 | Or the port range or dma port | 21:14 |
| mjg59 | There's the pnp_reserve_* arguments, but again those will only help if the device is being configured by pnp | 21:14 |
| mjg59 | In the general case what you're asking for is impossible | 21:15 |
| davygrvy | armed with the boot options I expect to find success, at least in the debugging area | 21:17 |
| davygrvy | pci=irqmask=0xMMMM | 21:20 |
| === Pricey is now known as EvilChild | ||
| lesshaste | hi | 22:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!