diff for duplicates of <1502985161.2615.8.camel@wdc.com> diff --git a/a/1.txt b/N1/1.txt index 6e95718..cddd3de 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,67 +1,65 @@ -On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote: -> On 08/16/2017 12:21 PM, Bart Van Assche wrote: -> > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote: -> > > As of next-20170809, linux-next on powerpc boot hung with below trace -> > > message. -> > > -> > > [ ... ] -> > > -> > > A bisection resulted in first bad commit (270065e92 - scsi: scsi-mq: -> > > Always unprepare ...) in the merge branch 'scsi/for-next' -> > > -> > > System booted fine when the below commit is reverted: -> > > -> > > commit 270065e92c317845d69095ec8e3d18616b5b39d5 -> > > Author: Bart Van Assche <bart.vanassche@wdc.com> -> > > Date: Thu Aug 3 14:40:14 2017 -0700 -> > > -> > > scsi: scsi-mq: Always unprepare before requeuing a request -> > -> > Hello Brian and Michael, -> > -> > Do you agree that this probably indicates a bug in the PowerPC block driver -> > that is used to access the boot disk? Anyway, since a solution is not yet -> > available, I will submit a revert for this patch. -> -> I've been looking at this a bit, and can recreate the issue, but haven't -> got to root cause of the issue as of yet. If I do a sysrq-w while the system is hung -> during boot I see this: -> -> [ 25.561523] Workqueue: events_unbound async_run_entry_fn -> [ 25.561527] Call Trace: -> [ 25.561529] [c0000001697873f0] [c000000169701600] 0xc000000169701600 (unreliable) -> [ 25.561534] [c0000001697875c0] [c00000000001ab78] __switch_to+0x2e8/0x430 -> [ 25.561539] [c000000169787620] [c00000000091ccb0] __schedule+0x310/0xa00 -> [ 25.561543] [c0000001697876f0] [c00000000091d3e0] schedule+0x40/0xb0 -> [ 25.561548] [c000000169787720] [c000000000921e40] schedule_timeout+0x200/0x430 -> [ 25.561553] [c000000169787810] [c00000000091db10] io_schedule_timeout+0x30/0x70 -> [ 25.561558] [c000000169787840] [c00000000091e978] wait_for_common_io.constprop.3+0x178/0x280 -> [ 25.561563] [c0000001697878c0] [c00000000047f7ec] blk_execute_rq+0x7c/0xd0 -> [ 25.561567] [c000000169787910] [c000000000614cd0] scsi_execute+0x100/0x230 -> [ 25.561572] [c000000169787990] [c00000000060d29c] scsi_report_opcode+0xbc/0x170 -> [ 25.561577] [c000000169787a50] [d000000004fe6404] sd_revalidate_disk+0xe04/0x1620 [sd_mod] -> [ 25.561583] [c000000169787b80] [d000000004fe6d84] sd_probe_async+0xb4/0x230 [sd_mod] -> [ 25.561588] [c000000169787c00] [c00000000010fc44] async_run_entry_fn+0x74/0x210 -> [ 25.561593] [c000000169787c90] [c000000000102f48] process_one_work+0x198/0x480 -> [ 25.561598] [c000000169787d30] [c0000000001032b8] worker_thread+0x88/0x510 -> [ 25.561603] [c000000169787dc0] [c00000000010b030] kthread+0x160/0x1a0 -> [ 25.561608] [c000000169787e30] [c00000000000b3a4] ret_from_kernel_thread+0x5c/0xb8 -> -> I was noticing that we are commonly in scsi_report_opcode. Since ipr RAID arrays don't support -> the MAINTENANCE_IN / MI_REPORT_SUPPORTED_OPERATION_CODES, I tried setting sdev->no_report_opcodes = 1 -> in ipr's slave configure. This seems to eliminate the boot hang for me, but is only working around -> the issue. Since this command is not supported by ipr, it should return with an illegal request. -> When I'm hung at this point, there is nothing outstanding to the adapter / driver. I'll continue -> debugging... - -(+linux-scsi) - -Hello Brian, - -Is kernel debugging enabled on your test system? Is lockdep enabled? -Anyway, stack traces like the above usually mean that a request got stuck in -a block or scsi driver (ipr in this case). Information about pending requests, -including the SCSI CDB, is available under /sys/kernel/debug/block (see also -commit 0eebd005dd07 ("scsi: Implement blk_mq_ops.show_rq()")). - -Bart. +T24gV2VkLCAyMDE3LTA4LTE2IGF0IDE4OjE4IC0wNTAwLCBCcmlhbiBLaW5nIHdyb3RlOg0KPiBP +biAwOC8xNi8yMDE3IDEyOjIxIFBNLCBCYXJ0IFZhbiBBc3NjaGUgd3JvdGU6DQo+ID4gT24gV2Vk +LCAyMDE3LTA4LTE2IGF0IDIyOjMwICswNTMwLCBBYmR1bCBIYWxlZW0gd3JvdGU6DQo+ID4gPiBB +cyBvZiBuZXh0LTIwMTcwODA5LCBsaW51eC1uZXh0IG9uIHBvd2VycGMgYm9vdCBodW5nIHdpdGgg +YmVsb3cgdHJhY2UNCj4gPiA+IG1lc3NhZ2UuDQo+ID4gPiANCj4gPiA+IFsgLi4uIF0NCj4gPiA+ +IA0KPiA+ID4gQSBiaXNlY3Rpb24gcmVzdWx0ZWQgaW4gZmlyc3QgYmFkIGNvbW1pdCAoMjcwMDY1 +ZTkyIC0gc2NzaTogc2NzaS1tcToNCj4gPiA+IEFsd2F5cyB1bnByZXBhcmUgLi4uKSBpbiB0aGUg +bWVyZ2UgYnJhbmNoICdzY3NpL2Zvci1uZXh0Jw0KPiA+ID4gDQo+ID4gPiBTeXN0ZW0gYm9vdGVk +IGZpbmUgd2hlbiB0aGUgYmVsb3cgY29tbWl0IGlzIHJldmVydGVkOiANCj4gPiA+IA0KPiA+ID4g +Y29tbWl0IDI3MDA2NWU5MmMzMTc4NDVkNjkwOTVlYzhlM2QxODYxNmI1YjM5ZDUNCj4gPiA+IEF1 +dGhvcjogQmFydCBWYW4gQXNzY2hlIDxiYXJ0LnZhbmFzc2NoZUB3ZGMuY29tPg0KPiA+ID4gRGF0 +ZTogICBUaHUgQXVnIDMgMTQ6NDA6MTQgMjAxNyAtMDcwMA0KPiA+ID4gDQo+ID4gPiAgICAgc2Nz +aTogc2NzaS1tcTogQWx3YXlzIHVucHJlcGFyZSBiZWZvcmUgcmVxdWV1aW5nIGEgcmVxdWVzdA0K +PiA+IA0KPiA+IEhlbGxvIEJyaWFuIGFuZCBNaWNoYWVsLA0KPiA+IA0KPiA+IERvIHlvdSBhZ3Jl +ZSB0aGF0IHRoaXMgcHJvYmFibHkgaW5kaWNhdGVzIGEgYnVnIGluIHRoZSBQb3dlclBDIGJsb2Nr +IGRyaXZlcg0KPiA+IHRoYXQgaXMgdXNlZCB0byBhY2Nlc3MgdGhlIGJvb3QgZGlzaz8gQW55d2F5 +LCBzaW5jZSBhIHNvbHV0aW9uIGlzIG5vdCB5ZXQNCj4gPiBhdmFpbGFibGUsIEkgd2lsbCBzdWJt +aXQgYSByZXZlcnQgZm9yIHRoaXMgcGF0Y2guDQo+IA0KPiBJJ3ZlIGJlZW4gbG9va2luZyBhdCB0 +aGlzIGEgYml0LCBhbmQgY2FuIHJlY3JlYXRlIHRoZSBpc3N1ZSwgYnV0IGhhdmVuJ3QNCj4gZ290 +IHRvIHJvb3QgY2F1c2Ugb2YgdGhlIGlzc3VlIGFzIG9mIHlldC4gSWYgSSBkbyBhIHN5c3JxLXcg +d2hpbGUgdGhlIHN5c3RlbSBpcyBodW5nDQo+IGR1cmluZyBib290IEkgc2VlIHRoaXM6DQo+IA0K +PiBbICAgMjUuNTYxNTIzXSBXb3JrcXVldWU6IGV2ZW50c191bmJvdW5kIGFzeW5jX3J1bl9lbnRy +eV9mbg0KPiBbICAgMjUuNTYxNTI3XSBDYWxsIFRyYWNlOg0KPiBbICAgMjUuNTYxNTI5XSBbYzAw +MDAwMDE2OTc4NzNmMF0gW2MwMDAwMDAxNjk3MDE2MDBdIDB4YzAwMDAwMDE2OTcwMTYwMCAodW5y +ZWxpYWJsZSkNCj4gWyAgIDI1LjU2MTUzNF0gW2MwMDAwMDAxNjk3ODc1YzBdIFtjMDAwMDAwMDAw +MDFhYjc4XSBfX3N3aXRjaF90bysweDJlOC8weDQzMA0KPiBbICAgMjUuNTYxNTM5XSBbYzAwMDAw +MDE2OTc4NzYyMF0gW2MwMDAwMDAwMDA5MWNjYjBdIF9fc2NoZWR1bGUrMHgzMTAvMHhhMDANCj4g +WyAgIDI1LjU2MTU0M10gW2MwMDAwMDAxNjk3ODc2ZjBdIFtjMDAwMDAwMDAwOTFkM2UwXSBzY2hl +ZHVsZSsweDQwLzB4YjANCj4gWyAgIDI1LjU2MTU0OF0gW2MwMDAwMDAxNjk3ODc3MjBdIFtjMDAw +MDAwMDAwOTIxZTQwXSBzY2hlZHVsZV90aW1lb3V0KzB4MjAwLzB4NDMwDQo+IFsgICAyNS41NjE1 +NTNdIFtjMDAwMDAwMTY5Nzg3ODEwXSBbYzAwMDAwMDAwMDkxZGIxMF0gaW9fc2NoZWR1bGVfdGlt +ZW91dCsweDMwLzB4NzANCj4gWyAgIDI1LjU2MTU1OF0gW2MwMDAwMDAxNjk3ODc4NDBdIFtjMDAw +MDAwMDAwOTFlOTc4XSB3YWl0X2Zvcl9jb21tb25faW8uY29uc3Rwcm9wLjMrMHgxNzgvMHgyODAN +Cj4gWyAgIDI1LjU2MTU2M10gW2MwMDAwMDAxNjk3ODc4YzBdIFtjMDAwMDAwMDAwNDdmN2VjXSBi +bGtfZXhlY3V0ZV9ycSsweDdjLzB4ZDANCj4gWyAgIDI1LjU2MTU2N10gW2MwMDAwMDAxNjk3ODc5 +MTBdIFtjMDAwMDAwMDAwNjE0Y2QwXSBzY3NpX2V4ZWN1dGUrMHgxMDAvMHgyMzANCj4gWyAgIDI1 +LjU2MTU3Ml0gW2MwMDAwMDAxNjk3ODc5OTBdIFtjMDAwMDAwMDAwNjBkMjljXSBzY3NpX3JlcG9y +dF9vcGNvZGUrMHhiYy8weDE3MA0KPiBbICAgMjUuNTYxNTc3XSBbYzAwMDAwMDE2OTc4N2E1MF0g +W2QwMDAwMDAwMDRmZTY0MDRdIHNkX3JldmFsaWRhdGVfZGlzaysweGUwNC8weDE2MjAgW3NkX21v +ZF0NCj4gWyAgIDI1LjU2MTU4M10gW2MwMDAwMDAxNjk3ODdiODBdIFtkMDAwMDAwMDA0ZmU2ZDg0 +XSBzZF9wcm9iZV9hc3luYysweGI0LzB4MjMwIFtzZF9tb2RdDQo+IFsgICAyNS41NjE1ODhdIFtj +MDAwMDAwMTY5Nzg3YzAwXSBbYzAwMDAwMDAwMDEwZmM0NF0gYXN5bmNfcnVuX2VudHJ5X2ZuKzB4 +NzQvMHgyMTANCj4gWyAgIDI1LjU2MTU5M10gW2MwMDAwMDAxNjk3ODdjOTBdIFtjMDAwMDAwMDAw +MTAyZjQ4XSBwcm9jZXNzX29uZV93b3JrKzB4MTk4LzB4NDgwDQo+IFsgICAyNS41NjE1OThdIFtj +MDAwMDAwMTY5Nzg3ZDMwXSBbYzAwMDAwMDAwMDEwMzJiOF0gd29ya2VyX3RocmVhZCsweDg4LzB4 +NTEwDQo+IFsgICAyNS41NjE2MDNdIFtjMDAwMDAwMTY5Nzg3ZGMwXSBbYzAwMDAwMDAwMDEwYjAz +MF0ga3RocmVhZCsweDE2MC8weDFhMA0KPiBbICAgMjUuNTYxNjA4XSBbYzAwMDAwMDE2OTc4N2Uz +MF0gW2MwMDAwMDAwMDAwMGIzYTRdIHJldF9mcm9tX2tlcm5lbF90aHJlYWQrMHg1Yy8weGI4DQo+ +IA0KPiBJIHdhcyBub3RpY2luZyB0aGF0IHdlIGFyZSBjb21tb25seSBpbiBzY3NpX3JlcG9ydF9v +cGNvZGUuIFNpbmNlIGlwciBSQUlEIGFycmF5cyBkb24ndCBzdXBwb3J0DQo+IHRoZSBNQUlOVEVO +QU5DRV9JTiAvIE1JX1JFUE9SVF9TVVBQT1JURURfT1BFUkFUSU9OX0NPREVTLCBJIHRyaWVkIHNl +dHRpbmcgc2Rldi0+bm9fcmVwb3J0X29wY29kZXMgPSAxDQo+IGluIGlwcidzIHNsYXZlIGNvbmZp +Z3VyZS4gVGhpcyBzZWVtcyB0byBlbGltaW5hdGUgdGhlIGJvb3QgaGFuZyBmb3IgbWUsIGJ1dCBp +cyBvbmx5IHdvcmtpbmcgYXJvdW5kDQo+IHRoZSBpc3N1ZS4gU2luY2UgdGhpcyBjb21tYW5kIGlz +IG5vdCBzdXBwb3J0ZWQgYnkgaXByLCBpdCBzaG91bGQgcmV0dXJuIHdpdGggYW4gaWxsZWdhbCBy +ZXF1ZXN0Lg0KPiBXaGVuIEknbSBodW5nIGF0IHRoaXMgcG9pbnQsIHRoZXJlIGlzIG5vdGhpbmcg +b3V0c3RhbmRpbmcgdG8gdGhlIGFkYXB0ZXIgLyBkcml2ZXIuIEknbGwgY29udGludWUNCj4gZGVi +dWdnaW5nLi4uDQoNCigrbGludXgtc2NzaSkNCg0KSGVsbG8gQnJpYW4sDQoNCklzIGtlcm5lbCBk +ZWJ1Z2dpbmcgZW5hYmxlZCBvbiB5b3VyIHRlc3Qgc3lzdGVtPyBJcyBsb2NrZGVwIGVuYWJsZWQ/ +DQpBbnl3YXksIHN0YWNrIHRyYWNlcyBsaWtlIHRoZSBhYm92ZSB1c3VhbGx5IG1lYW4gdGhhdCBh +IHJlcXVlc3QgZ290IHN0dWNrIGluDQphIGJsb2NrIG9yIHNjc2kgZHJpdmVyIChpcHIgaW4gdGhp +cyBjYXNlKS4gSW5mb3JtYXRpb24gYWJvdXQgcGVuZGluZyByZXF1ZXN0cywNCmluY2x1ZGluZyB0 +aGUgU0NTSSBDREIsIGlzIGF2YWlsYWJsZSB1bmRlciAvc3lzL2tlcm5lbC9kZWJ1Zy9ibG9jayAo +c2VlIGFsc28NCmNvbW1pdCAwZWViZDAwNWRkMDcgKCJzY3NpOiBJbXBsZW1lbnQgYmxrX21xX29w +cy5zaG93X3JxKCkiKSkuDQoNCkJhcnQu diff --git a/a/content_digest b/N1/content_digest index 4dcb65e..71b6a33 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -17,72 +17,70 @@ " mpe@ellerman.id.au <mpe@ellerman.id.au>\0" "\00:1\0" "b\0" - "On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote:\n" - "> On 08/16/2017 12:21 PM, Bart Van Assche wrote:\n" - "> > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote:\n" - "> > > As of next-20170809, linux-next on powerpc boot hung with below trace\n" - "> > > message.\n" - "> > > \n" - "> > > [ ... ]\n" - "> > > \n" - "> > > A bisection resulted in first bad commit (270065e92 - scsi: scsi-mq:\n" - "> > > Always unprepare ...) in the merge branch 'scsi/for-next'\n" - "> > > \n" - "> > > System booted fine when the below commit is reverted: \n" - "> > > \n" - "> > > commit 270065e92c317845d69095ec8e3d18616b5b39d5\n" - "> > > Author: Bart Van Assche <bart.vanassche@wdc.com>\n" - "> > > Date: Thu Aug 3 14:40:14 2017 -0700\n" - "> > > \n" - "> > > scsi: scsi-mq: Always unprepare before requeuing a request\n" - "> > \n" - "> > Hello Brian and Michael,\n" - "> > \n" - "> > Do you agree that this probably indicates a bug in the PowerPC block driver\n" - "> > that is used to access the boot disk? Anyway, since a solution is not yet\n" - "> > available, I will submit a revert for this patch.\n" - "> \n" - "> I've been looking at this a bit, and can recreate the issue, but haven't\n" - "> got to root cause of the issue as of yet. If I do a sysrq-w while the system is hung\n" - "> during boot I see this:\n" - "> \n" - "> [ 25.561523] Workqueue: events_unbound async_run_entry_fn\n" - "> [ 25.561527] Call Trace:\n" - "> [ 25.561529] [c0000001697873f0] [c000000169701600] 0xc000000169701600 (unreliable)\n" - "> [ 25.561534] [c0000001697875c0] [c00000000001ab78] __switch_to+0x2e8/0x430\n" - "> [ 25.561539] [c000000169787620] [c00000000091ccb0] __schedule+0x310/0xa00\n" - "> [ 25.561543] [c0000001697876f0] [c00000000091d3e0] schedule+0x40/0xb0\n" - "> [ 25.561548] [c000000169787720] [c000000000921e40] schedule_timeout+0x200/0x430\n" - "> [ 25.561553] [c000000169787810] [c00000000091db10] io_schedule_timeout+0x30/0x70\n" - "> [ 25.561558] [c000000169787840] [c00000000091e978] wait_for_common_io.constprop.3+0x178/0x280\n" - "> [ 25.561563] [c0000001697878c0] [c00000000047f7ec] blk_execute_rq+0x7c/0xd0\n" - "> [ 25.561567] [c000000169787910] [c000000000614cd0] scsi_execute+0x100/0x230\n" - "> [ 25.561572] [c000000169787990] [c00000000060d29c] scsi_report_opcode+0xbc/0x170\n" - "> [ 25.561577] [c000000169787a50] [d000000004fe6404] sd_revalidate_disk+0xe04/0x1620 [sd_mod]\n" - "> [ 25.561583] [c000000169787b80] [d000000004fe6d84] sd_probe_async+0xb4/0x230 [sd_mod]\n" - "> [ 25.561588] [c000000169787c00] [c00000000010fc44] async_run_entry_fn+0x74/0x210\n" - "> [ 25.561593] [c000000169787c90] [c000000000102f48] process_one_work+0x198/0x480\n" - "> [ 25.561598] [c000000169787d30] [c0000000001032b8] worker_thread+0x88/0x510\n" - "> [ 25.561603] [c000000169787dc0] [c00000000010b030] kthread+0x160/0x1a0\n" - "> [ 25.561608] [c000000169787e30] [c00000000000b3a4] ret_from_kernel_thread+0x5c/0xb8\n" - "> \n" - "> I was noticing that we are commonly in scsi_report_opcode. Since ipr RAID arrays don't support\n" - "> the MAINTENANCE_IN / MI_REPORT_SUPPORTED_OPERATION_CODES, I tried setting sdev->no_report_opcodes = 1\n" - "> in ipr's slave configure. This seems to eliminate the boot hang for me, but is only working around\n" - "> the issue. Since this command is not supported by ipr, it should return with an illegal request.\n" - "> When I'm hung at this point, there is nothing outstanding to the adapter / driver. I'll continue\n" - "> debugging...\n" - "\n" - "(+linux-scsi)\n" - "\n" - "Hello Brian,\n" - "\n" - "Is kernel debugging enabled on your test system? Is lockdep enabled?\n" - "Anyway, stack traces like the above usually mean that a request got stuck in\n" - "a block or scsi driver (ipr in this case). Information about pending requests,\n" - "including the SCSI CDB, is available under /sys/kernel/debug/block (see also\n" - "commit 0eebd005dd07 (\"scsi: Implement blk_mq_ops.show_rq()\")).\n" - "\n" - Bart. + "T24gV2VkLCAyMDE3LTA4LTE2IGF0IDE4OjE4IC0wNTAwLCBCcmlhbiBLaW5nIHdyb3RlOg0KPiBP\n" + "biAwOC8xNi8yMDE3IDEyOjIxIFBNLCBCYXJ0IFZhbiBBc3NjaGUgd3JvdGU6DQo+ID4gT24gV2Vk\n" + "LCAyMDE3LTA4LTE2IGF0IDIyOjMwICswNTMwLCBBYmR1bCBIYWxlZW0gd3JvdGU6DQo+ID4gPiBB\n" + "cyBvZiBuZXh0LTIwMTcwODA5LCBsaW51eC1uZXh0IG9uIHBvd2VycGMgYm9vdCBodW5nIHdpdGgg\n" + "YmVsb3cgdHJhY2UNCj4gPiA+IG1lc3NhZ2UuDQo+ID4gPiANCj4gPiA+IFsgLi4uIF0NCj4gPiA+\n" + "IA0KPiA+ID4gQSBiaXNlY3Rpb24gcmVzdWx0ZWQgaW4gZmlyc3QgYmFkIGNvbW1pdCAoMjcwMDY1\n" + "ZTkyIC0gc2NzaTogc2NzaS1tcToNCj4gPiA+IEFsd2F5cyB1bnByZXBhcmUgLi4uKSBpbiB0aGUg\n" + "bWVyZ2UgYnJhbmNoICdzY3NpL2Zvci1uZXh0Jw0KPiA+ID4gDQo+ID4gPiBTeXN0ZW0gYm9vdGVk\n" + "IGZpbmUgd2hlbiB0aGUgYmVsb3cgY29tbWl0IGlzIHJldmVydGVkOiANCj4gPiA+IA0KPiA+ID4g\n" + "Y29tbWl0IDI3MDA2NWU5MmMzMTc4NDVkNjkwOTVlYzhlM2QxODYxNmI1YjM5ZDUNCj4gPiA+IEF1\n" + "dGhvcjogQmFydCBWYW4gQXNzY2hlIDxiYXJ0LnZhbmFzc2NoZUB3ZGMuY29tPg0KPiA+ID4gRGF0\n" + "ZTogICBUaHUgQXVnIDMgMTQ6NDA6MTQgMjAxNyAtMDcwMA0KPiA+ID4gDQo+ID4gPiAgICAgc2Nz\n" + "aTogc2NzaS1tcTogQWx3YXlzIHVucHJlcGFyZSBiZWZvcmUgcmVxdWV1aW5nIGEgcmVxdWVzdA0K\n" + "PiA+IA0KPiA+IEhlbGxvIEJyaWFuIGFuZCBNaWNoYWVsLA0KPiA+IA0KPiA+IERvIHlvdSBhZ3Jl\n" + "ZSB0aGF0IHRoaXMgcHJvYmFibHkgaW5kaWNhdGVzIGEgYnVnIGluIHRoZSBQb3dlclBDIGJsb2Nr\n" + "IGRyaXZlcg0KPiA+IHRoYXQgaXMgdXNlZCB0byBhY2Nlc3MgdGhlIGJvb3QgZGlzaz8gQW55d2F5\n" + "LCBzaW5jZSBhIHNvbHV0aW9uIGlzIG5vdCB5ZXQNCj4gPiBhdmFpbGFibGUsIEkgd2lsbCBzdWJt\n" + "aXQgYSByZXZlcnQgZm9yIHRoaXMgcGF0Y2guDQo+IA0KPiBJJ3ZlIGJlZW4gbG9va2luZyBhdCB0\n" + "aGlzIGEgYml0LCBhbmQgY2FuIHJlY3JlYXRlIHRoZSBpc3N1ZSwgYnV0IGhhdmVuJ3QNCj4gZ290\n" + "IHRvIHJvb3QgY2F1c2Ugb2YgdGhlIGlzc3VlIGFzIG9mIHlldC4gSWYgSSBkbyBhIHN5c3JxLXcg\n" + "d2hpbGUgdGhlIHN5c3RlbSBpcyBodW5nDQo+IGR1cmluZyBib290IEkgc2VlIHRoaXM6DQo+IA0K\n" + "PiBbICAgMjUuNTYxNTIzXSBXb3JrcXVldWU6IGV2ZW50c191bmJvdW5kIGFzeW5jX3J1bl9lbnRy\n" + "eV9mbg0KPiBbICAgMjUuNTYxNTI3XSBDYWxsIFRyYWNlOg0KPiBbICAgMjUuNTYxNTI5XSBbYzAw\n" + "MDAwMDE2OTc4NzNmMF0gW2MwMDAwMDAxNjk3MDE2MDBdIDB4YzAwMDAwMDE2OTcwMTYwMCAodW5y\n" + "ZWxpYWJsZSkNCj4gWyAgIDI1LjU2MTUzNF0gW2MwMDAwMDAxNjk3ODc1YzBdIFtjMDAwMDAwMDAw\n" + "MDFhYjc4XSBfX3N3aXRjaF90bysweDJlOC8weDQzMA0KPiBbICAgMjUuNTYxNTM5XSBbYzAwMDAw\n" + "MDE2OTc4NzYyMF0gW2MwMDAwMDAwMDA5MWNjYjBdIF9fc2NoZWR1bGUrMHgzMTAvMHhhMDANCj4g\n" + "WyAgIDI1LjU2MTU0M10gW2MwMDAwMDAxNjk3ODc2ZjBdIFtjMDAwMDAwMDAwOTFkM2UwXSBzY2hl\n" + "ZHVsZSsweDQwLzB4YjANCj4gWyAgIDI1LjU2MTU0OF0gW2MwMDAwMDAxNjk3ODc3MjBdIFtjMDAw\n" + "MDAwMDAwOTIxZTQwXSBzY2hlZHVsZV90aW1lb3V0KzB4MjAwLzB4NDMwDQo+IFsgICAyNS41NjE1\n" + "NTNdIFtjMDAwMDAwMTY5Nzg3ODEwXSBbYzAwMDAwMDAwMDkxZGIxMF0gaW9fc2NoZWR1bGVfdGlt\n" + "ZW91dCsweDMwLzB4NzANCj4gWyAgIDI1LjU2MTU1OF0gW2MwMDAwMDAxNjk3ODc4NDBdIFtjMDAw\n" + "MDAwMDAwOTFlOTc4XSB3YWl0X2Zvcl9jb21tb25faW8uY29uc3Rwcm9wLjMrMHgxNzgvMHgyODAN\n" + "Cj4gWyAgIDI1LjU2MTU2M10gW2MwMDAwMDAxNjk3ODc4YzBdIFtjMDAwMDAwMDAwNDdmN2VjXSBi\n" + "bGtfZXhlY3V0ZV9ycSsweDdjLzB4ZDANCj4gWyAgIDI1LjU2MTU2N10gW2MwMDAwMDAxNjk3ODc5\n" + "MTBdIFtjMDAwMDAwMDAwNjE0Y2QwXSBzY3NpX2V4ZWN1dGUrMHgxMDAvMHgyMzANCj4gWyAgIDI1\n" + "LjU2MTU3Ml0gW2MwMDAwMDAxNjk3ODc5OTBdIFtjMDAwMDAwMDAwNjBkMjljXSBzY3NpX3JlcG9y\n" + "dF9vcGNvZGUrMHhiYy8weDE3MA0KPiBbICAgMjUuNTYxNTc3XSBbYzAwMDAwMDE2OTc4N2E1MF0g\n" + "W2QwMDAwMDAwMDRmZTY0MDRdIHNkX3JldmFsaWRhdGVfZGlzaysweGUwNC8weDE2MjAgW3NkX21v\n" + "ZF0NCj4gWyAgIDI1LjU2MTU4M10gW2MwMDAwMDAxNjk3ODdiODBdIFtkMDAwMDAwMDA0ZmU2ZDg0\n" + "XSBzZF9wcm9iZV9hc3luYysweGI0LzB4MjMwIFtzZF9tb2RdDQo+IFsgICAyNS41NjE1ODhdIFtj\n" + "MDAwMDAwMTY5Nzg3YzAwXSBbYzAwMDAwMDAwMDEwZmM0NF0gYXN5bmNfcnVuX2VudHJ5X2ZuKzB4\n" + "NzQvMHgyMTANCj4gWyAgIDI1LjU2MTU5M10gW2MwMDAwMDAxNjk3ODdjOTBdIFtjMDAwMDAwMDAw\n" + "MTAyZjQ4XSBwcm9jZXNzX29uZV93b3JrKzB4MTk4LzB4NDgwDQo+IFsgICAyNS41NjE1OThdIFtj\n" + "MDAwMDAwMTY5Nzg3ZDMwXSBbYzAwMDAwMDAwMDEwMzJiOF0gd29ya2VyX3RocmVhZCsweDg4LzB4\n" + "NTEwDQo+IFsgICAyNS41NjE2MDNdIFtjMDAwMDAwMTY5Nzg3ZGMwXSBbYzAwMDAwMDAwMDEwYjAz\n" + "MF0ga3RocmVhZCsweDE2MC8weDFhMA0KPiBbICAgMjUuNTYxNjA4XSBbYzAwMDAwMDE2OTc4N2Uz\n" + "MF0gW2MwMDAwMDAwMDAwMGIzYTRdIHJldF9mcm9tX2tlcm5lbF90aHJlYWQrMHg1Yy8weGI4DQo+\n" + "IA0KPiBJIHdhcyBub3RpY2luZyB0aGF0IHdlIGFyZSBjb21tb25seSBpbiBzY3NpX3JlcG9ydF9v\n" + "cGNvZGUuIFNpbmNlIGlwciBSQUlEIGFycmF5cyBkb24ndCBzdXBwb3J0DQo+IHRoZSBNQUlOVEVO\n" + "QU5DRV9JTiAvIE1JX1JFUE9SVF9TVVBQT1JURURfT1BFUkFUSU9OX0NPREVTLCBJIHRyaWVkIHNl\n" + "dHRpbmcgc2Rldi0+bm9fcmVwb3J0X29wY29kZXMgPSAxDQo+IGluIGlwcidzIHNsYXZlIGNvbmZp\n" + "Z3VyZS4gVGhpcyBzZWVtcyB0byBlbGltaW5hdGUgdGhlIGJvb3QgaGFuZyBmb3IgbWUsIGJ1dCBp\n" + "cyBvbmx5IHdvcmtpbmcgYXJvdW5kDQo+IHRoZSBpc3N1ZS4gU2luY2UgdGhpcyBjb21tYW5kIGlz\n" + "IG5vdCBzdXBwb3J0ZWQgYnkgaXByLCBpdCBzaG91bGQgcmV0dXJuIHdpdGggYW4gaWxsZWdhbCBy\n" + "ZXF1ZXN0Lg0KPiBXaGVuIEknbSBodW5nIGF0IHRoaXMgcG9pbnQsIHRoZXJlIGlzIG5vdGhpbmcg\n" + "b3V0c3RhbmRpbmcgdG8gdGhlIGFkYXB0ZXIgLyBkcml2ZXIuIEknbGwgY29udGludWUNCj4gZGVi\n" + "dWdnaW5nLi4uDQoNCigrbGludXgtc2NzaSkNCg0KSGVsbG8gQnJpYW4sDQoNCklzIGtlcm5lbCBk\n" + "ZWJ1Z2dpbmcgZW5hYmxlZCBvbiB5b3VyIHRlc3Qgc3lzdGVtPyBJcyBsb2NrZGVwIGVuYWJsZWQ/\n" + "DQpBbnl3YXksIHN0YWNrIHRyYWNlcyBsaWtlIHRoZSBhYm92ZSB1c3VhbGx5IG1lYW4gdGhhdCBh\n" + "IHJlcXVlc3QgZ290IHN0dWNrIGluDQphIGJsb2NrIG9yIHNjc2kgZHJpdmVyIChpcHIgaW4gdGhp\n" + "cyBjYXNlKS4gSW5mb3JtYXRpb24gYWJvdXQgcGVuZGluZyByZXF1ZXN0cywNCmluY2x1ZGluZyB0\n" + "aGUgU0NTSSBDREIsIGlzIGF2YWlsYWJsZSB1bmRlciAvc3lzL2tlcm5lbC9kZWJ1Zy9ibG9jayAo\n" + "c2VlIGFsc28NCmNvbW1pdCAwZWViZDAwNWRkMDcgKCJzY3NpOiBJbXBsZW1lbnQgYmxrX21xX29w\n" + cy5zaG93X3JxKCkiKSkuDQoNCkJhcnQu -e06c8e74082c3f4937bfa91c8b2093b62ce1d15f6944521741225926b0992fab +ff38d8cd490f82f449daacccd37f333539b3188520fcf134dcc0707c35d2133f
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.