Re: [arch-general] archlinux kernel 3.14.2-1 Broadcom BCM4312 firmware-files not found
On Fri, May 9, 2014 at 7:00 PM, Andreas Adelmann a.adelm...@arcor.de wrote: What have i done: reinstalled firmware b43-firmware-5.100.130 by using Kernel 3.14.1-1 and 3.14.2-1 - no success. Only reinstalling the module won't do. You need to recompile for every kernel. cheers! mar77i
[arch-general] kernel 3.14.2 hangs - VirtualBox suspected
Hi, I recently updated kernel to 3.14.2 and now I see i/o subsystem hang in few minutes after I start VirtualBox 4.3.10 machines (with Windows7). messages.log below. It looks like every process that tries to access /dev/md3 (even kworker and md3_resync) hangs forever. Anyone has similar problems? May 13 12:35:29 serenity kernel: kworker/u16:9 D 0 112 2 0x May 13 12:35:29 serenity kernel: Workqueue: writeback bdi_writeback_workfn (flush-9:3) May 13 12:35:29 serenity kernel: 8804175177c0 0046 88042fc575a0 880417518000 May 13 12:35:29 serenity kernel: 000146c0 880417517fd8 000146c0 880417518000 May 13 12:35:29 serenity kernel: 34ca04fb 880417517710 880412a11e10 8804175177b8 May 13 12:35:29 serenity kernel: Call Trace: May 13 12:35:29 serenity kernel: [81292817] ? check_blkcg_changed+0x57/0x210 May 13 12:35:29 serenity kernel: [81145d35] ? mempool_alloc_slab+0x15/0x20 May 13 12:35:29 serenity kernel: [8128ce7f] ? blk_throtl_bio+0x35f/0x940 May 13 12:35:29 serenity kernel: [81145d35] ? mempool_alloc_slab+0x15/0x20 May 13 12:35:29 serenity kernel: [81145df1] ? mempool_alloc+0x61/0x170 May 13 12:35:29 serenity kernel: [a04fe523] ? __ext4_handle_dirty_metadata+0x83/0x1a0 [ext4] May 13 12:35:29 serenity kernel: [8150b609] schedule+0x29/0x70 May 13 12:35:29 serenity kernel: [a048a666] wait_barrier+0xc6/0x190 [raid10] May 13 12:35:29 serenity kernel: [810b4020] ? __wake_up_sync+0x20/0x20 May 13 12:35:29 serenity kernel: [a048eca4] make_request+0x44/0x130 [raid10] May 13 12:35:29 serenity kernel: [a0458a83] md_make_request+0x103/0x260 [md_mod] May 13 12:35:29 serenity kernel: [81145d35] ? mempool_alloc_slab+0x15/0x20 May 13 12:35:29 serenity kernel: [81145df1] ? mempool_alloc+0x61/0x170 May 13 12:35:29 serenity kernel: [8126f728] generic_make_request+0xf8/0x150 May 13 12:35:29 serenity kernel: [8126f7f8] submit_bio+0x78/0x190 May 13 12:35:29 serenity kernel: [811ef800] _submit_bh+0x140/0x230 May 13 12:35:29 serenity kernel: [811f1379] __block_write_full_page+0x129/0x370 May 13 12:35:29 serenity kernel: [811f4c70] ? I_BDEV+0x10/0x10 May 13 12:35:29 serenity kernel: [811f17d2] block_write_full_page_endio+0xb2/0x150 May 13 12:35:29 serenity kernel: [811f1885] block_write_full_page+0x15/0x20 May 13 12:35:29 serenity kernel: [811f53f8] blkdev_writepage+0x18/0x20 May 13 12:35:29 serenity kernel: [8114e0f3] __writepage+0x13/0x40 May 13 12:35:29 serenity kernel: [8114e680] write_cache_pages+0x1e0/0x4d0 May 13 12:35:29 serenity kernel: [8114e0e0] ? mapping_tagged+0x20/0x20 May 13 12:35:29 serenity kernel: [8114e9bd] generic_writepages+0x4d/0x80 May 13 12:35:29 serenity kernel: [811504ee] do_writepages+0x1e/0x30 May 13 12:35:29 serenity kernel: [811e5dc0] __writeback_single_inode+0x40/0x2b0 May 13 12:35:29 serenity kernel: [811e72ca] writeback_sb_inodes+0x26a/0x430 May 13 12:35:29 serenity kernel: [811e752f] __writeback_inodes_wb+0x9f/0xd0 May 13 12:35:29 serenity kernel: [811e778b] wb_writeback+0x22b/0x360 May 13 12:35:29 serenity kernel: [811d4361] ? get_nr_inodes+0x51/0x70 May 13 12:35:29 serenity kernel: [811e7d5f] bdi_writeback_workfn+0x33f/0x4c0 May 13 12:35:29 serenity kernel: [81088068] process_one_work+0x168/0x450 May 13 12:35:29 serenity kernel: [81088ac2] worker_thread+0x132/0x3e0 May 13 12:35:29 serenity kernel: [81088990] ? manage_workers.isra.23+0x2d0/0x2d0 May 13 12:35:29 serenity kernel: [8108f2ea] kthread+0xea/0x100 May 13 12:35:29 serenity kernel: [8108f200] ? kthread_create_on_node+0x1a0/0x1a0 May 13 12:35:29 serenity kernel: [8151757c] ret_from_fork+0x7c/0xb0 May 13 12:35:29 serenity kernel: [8108f200] ? kthread_create_on_node+0x1a0/0x1a0 May 13 12:35:29 serenity kernel: jbd2/md3-8 D 0 496 2 0x May 13 12:35:29 serenity kernel: 8804136e5ca0 0046 0001 88041963ce80 May 13 12:35:29 serenity kernel: 000146c0 8804136e5fd8 000146c0 88041963ce80 May 13 12:35:29 serenity kernel: 8804136e5bf0 8119d6e6 0046 May 13 12:35:29 serenity kernel: Call Trace: May 13 12:35:29 serenity kernel: [8119d6e6] ? kmem_cache_free+0x216/0x240 May 13 12:35:29 serenity kernel: [810ba100] ? cpuacct_charge+0x50/0x60 May 13 12:35:29 serenity kernel: [810a991c] ? update_curr+0xec/0x1b0 May 13 12:35:29 serenity kernel: [810a9e8f] ? dequeue_entity+0x13f/0x580 May 13 12:35:29 serenity kernel: [8150b609] schedule+0x29/0x70 May 13 12:35:29 serenity kernel:
Re: [arch-general] kernel 3.14.2 hangs - VirtualBox suspected
I recently updated kernel to 3.14.2 and now I see i/o subsystem hang in few minutes after I start VirtualBox 4.3.10 machines (with Windows7). messages.log below. It looks like every process that tries to access /dev/md3 (even kworker and md3_resync) hangs forever. Anyone has similar problems? I also use soft raid1 so I just ran W7 on my 3.14.3 and it just works. You are probably hitting some bad sector. VM disk is on /dev/md3, isn't it? You may want to `cat` read the VM disk file, and dd `read` the whole drives and the md drive to see if they are readable. You may want to inspect /proc/mdstat, /sys/block/**/bad_blocks and smartctl reports. You may be facing some bug in the raid drivers. I faced one too, which was then fixed. https://bugzilla.kernel.org/show_bug.cgi?id=68181 If it *is* a bug, the best what you can do is to report the bug, and keep the the current raid mirror as long as possible so you can tests patches the kernel guys provide. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
Re: [arch-general] kernel 3.14.2 hangs - VirtualBox suspected
Yes, I had bad sector on md3 (raid10) array. Disk was replaced. But it looks like it is unrelated to the reason why my box is hanging. It started after kernel update from 3.10 to 3.14.2 and vbox to 4.3.10. Now i updated kernel to 3.14.3, going 4h from update and it looks like my problem is gone. Regards, Łukasz On 05/13/14 15:39, Nowaker wrote: I recently updated kernel to 3.14.2 and now I see i/o subsystem hang in few minutes after I start VirtualBox 4.3.10 machines (with Windows7). messages.log below. It looks like every process that tries to access /dev/md3 (even kworker and md3_resync) hangs forever. Anyone has similar problems? I also use soft raid1 so I just ran W7 on my 3.14.3 and it just works. You are probably hitting some bad sector. VM disk is on /dev/md3, isn't it? You may want to `cat` read the VM disk file, and dd `read` the whole drives and the md drive to see if they are readable. You may want to inspect /proc/mdstat, /sys/block/**/bad_blocks and smartctl reports. You may be facing some bug in the raid drivers. I faced one too, which was then fixed. https://bugzilla.kernel.org/show_bug.cgi?id=68181 If it *is* a bug, the best what you can do is to report the bug, and keep the the current raid mirror as long as possible so you can tests patches the kernel guys provide.
Re: [arch-general] systemd-run --user does not work
On Mon, May 12, 2014 at 8:04 PM, Ismael Bouya
ismael.bo...@normalesup.org wrote:
For me it works both with user and system.
[skip instructions]
(Note that your shell doesn't have to know the DBUS_SESSION_BUS_ADDRESS
variable)
Thank you!! I have followed your instructions and it actually works,
although I have to run:
$ export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus
before being able to run systemd-run.
What I don't understand is why. Why systemd-run needs the
dbus-session daemon while systemctl works perfectly fine without it?
Both programs ultimately call to the same interface [0], don't they?
After some investigation, it looks like the user systemd daemon
creates a private dbus address in /run/user/$(id
-u)/systemd/private. Then, systemctl uses this private socket, while
systemd-run uses the standard, session, dbus-daemon, if the systemd
user daemon is able to connect to it (that's where I had failed but
Ismael succeeded).
Now, my question is:
Why doesn't systemd-run use the private socket address, just as systemctl does?
And now that we are into it, why is a separated program? Why not
systemctl run or systemctl transient-run? Maybe too many different
command-line options?
Just to prove my point I managed to create a user transient unit
without using the session bus, running this command:
$ gdbus call -a unix:path=/run/user/$(id -u)/systemd/private -o
/org/freedesktop/systemd1 -m
org.freedesktop.systemd1.Manager.StartTransientUnit \
run-$RANDOM.service fail \
[('ExecStart', [('/usr/bin/ls', ['/usr/bin/ls','-l'], false)])] \
[]
Yes... it took me a while to get the right syntax ;-)
Maybe I should move this as a request for upstream?
--
Rodrigo
[0]: http://www.freedesktop.org/wiki/Software/systemd/dbus/
Re: [arch-general] systemd-run --user does not work
Hi, I don't know if it's necessary to send the request upstream for the moment: They are busy moving things to kdbus (which is the kernel implementation of dbus, and not KDE-dbus as I thought initially). Things are actually slightly messed up currently (that's my opinion, when I spent time reading the systemd code to write my tutorial). The best thing to be sure that everything works is to make sure that all of your processes have the information about DBUS_SESSION_BUS_ADDRESS, and the same information (and that dbus --session is started also, of course). Some processes spawn a dbus when they cannot find one, which makes things harder to debug (because they won't complain but it won't work as expected as they will have their own bus and noone can talk to them. And you end with two dbus processes just for you) About the difference between systemd-run and systemctl: I didn't have a close look at the systemd-run code, but they seem to have a different way of implementing dbus connections (which might come from the comment above, or simply legacy code). And I also ran into trouble with systemctl when I didn't have the DBUS part (I cannot remember which kind of problems, but that's where I started to dive into details of systemd implementation) So to sum up: if you have it everywhere it works; so why not put it and forget about it (it's not so hard to ensure actually). -- Ismael signature.asc Description: Digital signature
Re: [arch-general] systemd-run --user does not work
On Tue, May 13, 2014 at 3:04 AM, Ismael Bouya ismael.bo...@normalesup.orgwrote: [snip-explanation] -- Ismael Thank you, Ismael. I've not yet implemented what you've suggested (been a bit busy), but I'll report back once I get the time to play with my laptop. I'm certain it works, as your explanation makes a lot of sense. -- Savyasachee Jha *Aerodynamics is for people whodon't know how to build engines.*
