RPi sẽ bị lỗi Y2K38?


12

Vì tò mò, điều gì sẽ xảy ra với RPis Model A và B vào ngày 19 tháng 1 năm 2038 trong 3:14:07 sáng GMT? Họ có bị ảnh hưởng bởi lỗi Y2K38 không?


Bao nhiêu bạn mong đợi vẫn còn chạy sau đó?
Thorbjørn Ravn Andersen

1
@ ThorbjørnRavnAndersen thành thật Tôi tin rằng RPi có tương lai lớn và sẽ có nhiều người trong số họ vẫn chạy (cuối cùng là mô hình C hoặc lớn hơn nhưng ..)
DaGhostman Dimitrov 30/12/13

5
Trong trường hợp đó, đặt đồng hồ và xem.
Thorbjørn Ravn Andersen

1
Không nghĩ về điều đó ..: D
DaGhostman Dimitrov

1
Dù tương lai của pi là gì đi nữa, rất có thể nó cũng không phải là thứ gì khác sẽ vẫn sử dụng bộ xử lý 32 bit trong 25 năm. Theo wikipedia, các hệ thống 64 bit sử dụng 64 bit time_t, biến vấn đề này thành vấn đề Y292G , điều mà cả chúng ta và mặt trời sẽ không thể thấy được.
goldilocks

Câu trả lời:


10

Đúng.

Đây là đầu ra của phiên SSH tới Pi của tôi đang chạy OpenELEC.

Nó bị treo sau khi đạt Y2K38. Không chỉ phiên SSH tự dừng phản hồi, mà OpenELEC cũng đóng băng.

Tôi hy vọng (và hy vọng!) Rằng vào năm 2038, một bản sửa lỗi sẽ được phát hành.

Điều đó, hoặc câu hỏi của bạn sẽ nhận được rất nhiều sự ủng hộ trong 24 năm.

nhập mô tả hình ảnh ở đây


Tôi ngạc nhiên khi bạn có thể mở một phiên SSH với một máy có ngày hết hạn như vậy. +1 để thực sự thử nó mặc dù.
vô tư

@einnocent Tại sao tôi không thể? Có bất kỳ loại so sánh thời gian nào trên các thông số kỹ thuật bắt tay SSH sẽ ngăn chặn nó không? Ngoài ra, tôi đã thay đổi thời gian sau khi kết nối được thiết lập. Bên cạnh đó, đồng hồ Pi dù sao cũng đã sai (vài tháng, nhiều năm, không thể nhớ lại): P
Chàng trai người Brazil

Thay đổi thời gian kết nối trước, tôi hiểu rằng sự khác biệt lớn về thời gian đồng hồ có thể gây ra sự cố với một số bắt tay bảo mật, mặc dù tôi không biết cụ thể về SSH. Với một thay đổi sau kết nối, tôi có thể tưởng tượng SSH đột nhiên phát hoảng khi phát hiện ra nó có kết nối mở trong 34 năm. Tôi cho rằng có một cơ hội nhỏ (nhưng khác không) rằng SSH chỉ đơn giản là kết thúc kết nối vào thời điểm kỳ diệu đó. Nhưng thực sự tôi đang thuyết phục với câu trả lời của bạn :)
einnocent

@einnocent Điều đó không xảy ra với tôi rằng SSH có thể nghĩ rằng nó "mở trong 24 năm" và bị treo. Tôi sẽ thử lại với, nói, 22 năm. Nhưng tôi nghĩ đó không phải là nguyên nhân, bởi vì nó bị treo chính xác khi đạt Y2K38
chàng người Brazil đó

4

Trên thực tế Raspberry Pi (phần cứng) sẽ ổn. Nó không chứa RTC, vì vậy nó sẽ phụ thuộc vào hệ điều hành bạn sử dụng.

Nhưng IIRC tất cả phiên bản 32 bit của Linux đều có vấn đề này. Cách đây không lâu (10 năm hoặc hơn) Linus nói rằng anh ta không thú vị khi sửa lỗi này trên nền tảng 32 bit và tất cả các nền tảng 64 bit Linux tại thời điểm đó có 64 bit time_t. Anh ấy có thể đã thay đổi là tâm trí từ đó tất nhiên. Liên kết tốt nhất mà tôi có thể tìm thấy là http://permalink.gmane.org/gmane.linux.kernel/1184914 - không giống nhau, nhưng thể hiện một ý định tương tự.

Nó sẽ không phải là một điều đặc biệt khó thay đổi, nhưng nó sẽ buộc một sự thay đổi trong nhân ABI. Đó là một vấn đề trong chính nó.

Nhưng, RiscOs sử dụng thời gian 40 bit (centisecond), nhưng với một Epoch khác. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - Tôi thực hiện điều đó vào lúc nào đó vào năm 2318 - [calc là: 1970 + ((2 ^ 40) / 100) / (60 * 60 * 24 * 365.25)]

Android, tất nhiên sử dụng nhân Linux. Và tôi chắc chắn tôi đã bỏ lỡ các lựa chọn khác.


1

Như hiện đang được triển khai, Raspberry Pi sẽ chịu số phận của lỗi được liệt kê, nếu không có thay đổi nào trong phần mềm.

Hầu hết các máy móc hiện đại đang thực hiện bước nhảy lên bộ xử lý 64 bit, nhưng tôi sẽ không ngạc nhiên khi vẫn thấy bộ xử lý chính thống 32 bit vào thời điểm đó. Có những giải pháp phần mềm có thể và sẽ phải giải quyết vấn đề.

Dường như với tôi rằng cách khắc phục có khả năng nhất là cập nhật thời gian Epoch để bắt đầu vào ngày 1 tháng 1 năm 2000. Mặc dù điều này sẽ không trì hoãn lỗi, nhưng chắc chắn nó sẽ đặt lại nó trong tương lai gần.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.