{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":7921448,"defaultBranch":"main","name":"freebsd-src","ownerLogin":"dumbbell","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2013-01-30T19:00:12.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/159804?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1676551527.280757","currentOid":""},"activityList":{"items":[{"before":"2c5ff9118c1ed8483a9477db3595b1d154615e2c","after":"4e7aa03b7076353af4b960ade67f093af5736d38","ref":"refs/heads/main","pushedAt":"2024-04-08T11:05:36.000Z","pushType":"push","commitsCount":973,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"LinuxKPI: Stub sysfs_remove_link in linux/sysfs.h\n\nsysfs_create_link is stubbed already. Stub sysfs_remove_link too to be\nfeature-complete.\n\nSponsored by:\tSerenity Cyber Security, LLC\nReviewed by:\temaste\nMFC after:\t1 week","shortMessageHtmlLink":"LinuxKPI: Stub sysfs_remove_link in linux/sysfs.h"}},{"before":"13037eaabede7fb7fbc25f4e84b549c73f9acb3c","after":"2c5ff9118c1ed8483a9477db3595b1d154615e2c","ref":"refs/heads/main","pushedAt":"2024-02-15T18:21:46.000Z","pushType":"push","commitsCount":1304,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"rights.4: Remove sentence implying that rights are a mask\n\nCapability rights passed to cap_rights_* are (now) not simple bitmaks\nand cannot be ORed together in general (although it will work for\ncertain subsets of rights).\n\nRemove sentence that implied rights are masks. We already have the\nsentence \"The complete list of capability rights is provided below\" so\nlisting the rights without an introductory sentence seems fine.\n\nPR:\t\t277057","shortMessageHtmlLink":"rights.4: Remove sentence implying that rights are a mask"}},{"before":"fe84281803d62a6846ecab5f5a7c8b4e49b0f0e0","after":"13037eaabede7fb7fbc25f4e84b549c73f9acb3c","ref":"refs/heads/main","pushedAt":"2023-12-25T13:38:22.000Z","pushType":"push","commitsCount":177,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"ig4: Actively use FIFO thresholds\n\nBefore every wait for FIFO interrupt set how much data/space do we\nwant to see there. Previous code was not using it for receive, as\nresult aggregating interrupts only within processing latency. The\nnew code needs only one interrupt per transfer per FIFO length.\n\nOn my Dell XPS 13 9310 with iichid(4) touchscreen and touchpad this\nreduces the interrupt rate per device down to 2 per sample or 16-20\nper second when idle and 120-160 per second when actively touched.\n\nMFC after:\t1 month","shortMessageHtmlLink":"ig4: Actively use FIFO thresholds"}},{"before":"ac4ec506b546bfc18e560bfe86b0ba191aacab93","after":"88d7129d8ce1905cfb69e9f78d2d838cda4b3057","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-13T19:00:28.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"d6d1e73e5f66f3b12881fffceff58ca54b506792","after":"fe84281803d62a6846ecab5f5a7c8b4e49b0f0e0","ref":"refs/heads/main","pushedAt":"2023-12-13T19:00:18.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"linuxkpi: Add `struct kset` support in \n\n[Why]\nThe amdgpu DRM driver started to use it in Linux 5.18.\n\nReviewed by:\tmanu\nApproved by:\tmanu\nDifferential Revision:\thttps://reviews.freebsd.org/D43020","shortMessageHtmlLink":"linuxkpi: Add struct kset
support in <linux/kobject.h>"}},{"before":"717ed078376798210e88da9a9c54fce278669536","after":"ac4ec506b546bfc18e560bfe86b0ba191aacab93","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-13T18:56:14.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"59cbead6b15fd2320fa0a98dc680aef5d6e1438f","after":"d6d1e73e5f66f3b12881fffceff58ca54b506792","ref":"refs/heads/main","pushedAt":"2023-12-13T18:56:00.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"linuxkpi: Include from \n\n[Why]\nThe i915 DRM driver in Linux 5.18 relies on this indirect include.\n\nReviewed by:\tmanu\nApproved by:\tmanu\nDifferential Revision:\thttps://reviews.freebsd.org/D43030","shortMessageHtmlLink":"linuxkpi: Include <linux/string_helpers.h> from <linux/seq_file.h>"}},{"before":"641eba2de4b4f238d2a9d37ab975a13129376d29","after":"59cbead6b15fd2320fa0a98dc680aef5d6e1438f","ref":"refs/heads/main","pushedAt":"2023-12-13T18:44:53.000Z","pushType":"push","commitsCount":8,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"linuxkpi: Add support for `suspend_noirq` callback in `struct dev_pm_ops`\n\n[Why]\nThis callback is being used by the amdgpu DRM driver in Linux 5.18.\n\n[How]\nThe callback is called after `suspend_late()`.\n\nReviewed by:\temaste, manu\nApproved by:\temaste, manu\nDifferential Revision:\thttps://reviews.freebsd.org/D43029","shortMessageHtmlLink":"linuxkpi: Add support for suspend_noirq
callback in `struct dev_pm_…"}},{"before":"b96b341e7fa5f22b2ca2e7593e75d023deac8e0a","after":"717ed078376798210e88da9a9c54fce278669536","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-13T18:43:58.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"da5c4020f5fc4845f4d0088beea3faada1b62ef4","after":"b96b341e7fa5f22b2ca2e7593e75d023deac8e0a","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-13T18:29:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"97530894fc142a9c44a5909e6ae668dc95a5036a","after":"641eba2de4b4f238d2a9d37ab975a13129376d29","ref":"refs/heads/main","pushedAt":"2023-12-13T18:18:34.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"Makefile.inc1: Reinstate building sbin/md5 for BOOTSTRAP_ALL_TOOLS\n\nThe sha256 and sha512 binaries are used when building release images.\nBootstrapping them used to be gated on MK_BOOT, which wasn't quite right\nbut in practice worked, at least in our use cases downstream. Add back\nbootstrapping sbin/md5 and its aliases for this purpose to fix building\nrelease images on Linux and macOS.\n\nFixes:\tf213da893ca8 (\"Makefile.inc1: Remove beri straggler\")","shortMessageHtmlLink":"Makefile.inc1: Reinstate building sbin/md5 for BOOTSTRAP_ALL_TOOLS"}},{"before":"52dd07dcacd48fe8604ecc3ec4cd6136eb0f1490","after":"da5c4020f5fc4845f4d0088beea3faada1b62ef4","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-13T17:51:26.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"b292c995cfa88cc73d5d77b6b94ae1b78296793f","after":"97530894fc142a9c44a5909e6ae668dc95a5036a","ref":"refs/heads/main","pushedAt":"2023-12-13T11:46:14.000Z","pushType":"push","commitsCount":215,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kldxref: fix build on 32 bits arches","shortMessageHtmlLink":"kldxref: fix build on 32 bits arches"}},{"before":"5fd9d1a723c042aa1f235753c4b722b54d77b385","after":"52dd07dcacd48fe8604ecc3ec4cd6136eb0f1490","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-09T16:40:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"c724344ba9038434113dc47b4422e89abb7de32a","after":"5fd9d1a723c042aa1f235753c4b722b54d77b385","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-08T22:06:06.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"63ba32e40818a1959e508fbb19734c355d0471a4","after":"c724344ba9038434113dc47b4422e89abb7de32a","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-07T20:55:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"a355514a6e83a544f7131100244ff3193833e823","after":"63ba32e40818a1959e508fbb19734c355d0471a4","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-04T23:07:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"a0067c47f2861080212a11f11589fad305919bcd","after":"a355514a6e83a544f7131100244ff3193833e823","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-12-02T10:51:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"49a83b94395a6eaae4642aa72c9f6a40143f0f45","after":"b292c995cfa88cc73d5d77b6b94ae1b78296793f","ref":"refs/heads/main","pushedAt":"2023-11-29T18:55:50.000Z","pushType":"push","commitsCount":147,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"linuxkpi: Include from and \n\n[Why]\nSome files in DRM rely on this indirect include to use `struct rb_*`.\n\nReviewed by:\tmanu\nApproved by:\tmanu\nDifferential Revision:\thttps://reviews.freebsd.org/D42835","shortMessageHtmlLink":"linuxkpi: Include <linux/rbtree.h> from <linux/hrtimer.h> and <linux/…"}},{"before":"ad66a8837fc7d4073f11f3095457182fd5ed7639","after":"a0067c47f2861080212a11f11589fad305919bcd","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-11-29T18:55:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"1c184193b072714be83184d759b9eafcda985f7d","after":"ad66a8837fc7d4073f11f3095457182fd5ed7639","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-11-29T18:46:51.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"39ae0775cc66a0d43aae7f5fc1b373f46b7ec91e","after":"1c184193b072714be83184d759b9eafcda985f7d","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-11-29T18:40:57.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"55b49df36e69571ef338568655630598c4d46f64","after":"39ae0775cc66a0d43aae7f5fc1b373f46b7ec91e","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-11-25T11:11:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"f18b3ce0b7be0b24a743ec59077ca8e7929a353c","after":"49a83b94395a6eaae4642aa72c9f6a40143f0f45","ref":"refs/heads/main","pushedAt":"2023-11-25T10:39:23.000Z","pushType":"push","commitsCount":9,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"stress2: Do not make assumptions about the value of UFS_LINK_MAX","shortMessageHtmlLink":"stress2: Do not make assumptions about the value of UFS_LINK_MAX"}},{"before":"73902ed85ab73d455d4be8c77336c88a07512230","after":"f18b3ce0b7be0b24a743ec59077ca8e7929a353c","ref":"refs/heads/main","pushedAt":"2023-11-24T17:32:26.000Z","pushType":"push","commitsCount":11,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"vt(4): Always call vt_window_switch() in vtterm_cnungrab()\n\n[Why]\nThis ensures that vtterm_cnungrab() is the mirror of vtterm_cngrab().\nAnd the latter always call vt_window_switch() and thus the backend's\nvd_postswitch().\n\nThis makes sure that whatever the backend did during vtterm_cngrab(), it\ncan undo it during vtterm_cnungrab().\n\nReviewed by:\tmanu\nApproved by:\tmanu\nDifferential Revision:\thttps://reviews.freebsd.org/D42752","shortMessageHtmlLink":"vt(4): Always call vt_window_switch() in vtterm_cnungrab()"}},{"before":"4f9aa04ff3eb6fcda69d6aafdf506db544d3fa71","after":"55b49df36e69571ef338568655630598c4d46f64","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-11-24T17:32:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"0c5cd045bfb847428a8a5e0e91e6fc3cf27a17c2","after":"73902ed85ab73d455d4be8c77336c88a07512230","ref":"refs/heads/main","pushedAt":"2023-11-24T17:31:01.000Z","pushType":"push","commitsCount":441,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"ldconfig: only configure compat32 when kernel supports it\n\nand eliminate hard-coded arch list.\n\nReviewed by:\tmarkj\nSponsored by:\tThe FreeBSD Foundation\nMFC after:\t1 week\nDifferential revision:\thttps://reviews.freebsd.org/D42669","shortMessageHtmlLink":"ldconfig: only configure compat32 when kernel supports it"}},{"before":"0cb25cfa113192e1b784b7e3b7aef147ad7efbbe","after":"4f9aa04ff3eb6fcda69d6aafdf506db544d3fa71","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-11-24T17:30:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"8903b1869ee1d8842837b41f150fa7eef570cafc","after":"0cb25cfa113192e1b784b7e3b7aef147ad7efbbe","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-11-24T17:27:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}},{"before":"be68cc9b83184ea152b31fdf6330cbd8de3fc94c","after":"8903b1869ee1d8842837b41f150fa7eef570cafc","ref":"refs/heads/linuxkpi-updates-for-drm","pushedAt":"2023-11-24T16:51:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dumbbell","name":"Jean-Sébastien Pédron","path":"/dumbbell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/159804?s=80&v=4"},"commit":{"message":"kern_shutdown: Always request a core dump in `vpanic()`\n\n... even for a panic triggered while handling another one.\n\n[Why]\nIf some code crashes while a panic is handled, we didn't get a kernel\ncore dump so far.\n\nIt is frustrating while working on the DRM drivers and their integration\nwith vt(4) because it makes debugging more difficult. Indeed, a panic\nwill usually display something on the console. If displaying something\non the console triggered another panic in vt(4) or the DRM drivers\nbefore this patch, we wouldn't get any core dump.\n\n[How]\nThe `RB_DUMP` flag is always set, not only for the top-level panic.\n\nReviewed by:\nApproved by:\nDifferential Revision: https://reviews.freebsd.org/D42055","shortMessageHtmlLink":"kern_shutdown: Always request a core dump in vpanic()
"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEKtIozQA","startCursor":null,"endCursor":null}},"title":"Activity · dumbbell/freebsd-src"}